{"id":"CVE-2026-17351","summary":"pgAdmin 4: AI Assistant read-only transaction bypass via sqlparse/PostgreSQL lexer disagreement (incomplete fix for CVE-2026-12045)","details":"The fix for CVE-2026-12045 in pgAdmin 4 9.16 required the LLM-supplied query passed to the AI Assistant's execute_sql_query tool to parse, via sqlparse, as exactly one non-transaction-control statement before running it inside a BEGIN TRANSACTION READ ONLY wrapper. sqlparse's string-literal lexing can disagree with PostgreSQL's own parser: under standard_conforming_strings = on (PostgreSQL's default since 9.1), a backslash immediately before a quote is an ordinary character to PostgreSQL, but sqlparse treats it as escaping the quote. A payload such as SELECT '\\';COMMIT;CREATE TABLE pwn(x int);SELECT 1 --' therefore parses as a single SELECT to sqlparse's validator, while PostgreSQL executes it as four statements: the smuggled COMMIT ends the wrapping read-only transaction, and the trailing ROLLBACK becomes a no-op. This reintroduces the same write/RCE bypass CVE-2026-12045 was meant to close, reachable via the same indirect prompt-injection delivery (an attacker plants the payload in any object the AI Assistant may read; the LLM emits it as a tool call).\n\nAn initial candidate fix ran the query with psycopg's execute(..., prepare=True), intending to force PostgreSQL's own Parse step (extended query protocol) to reject multi-statement text regardless of sqlparse's classification. This candidate fix does not work as submitted: psycopg3's PrepareManager silently ignores the prepare argument whenever the connection's prepare_threshold is None, which is pgAdmin's default for every server connection (the per-server \"Prepare threshold\" field is blank unless an administrator explicitly sets it) -- psycopg3 falls back to the simple query protocol, the same multi-statement-capable path the bypass exploits, so the candidate fix closes nothing on any real-world default configuration.\n\nThe corrected fix sets conn.prepare_threshold = 0 directly on the dedicated, single-use read-only connection the AI Assistant tool opens, structurally forcing the extended query protocol independent of any server-level configuration. Verified against a live PostgreSQL 18 instance: the payload executes successfully under the prepare_threshold=None (default) behavior, and is rejected with \"cannot insert multiple commands into a prepared statement\" once prepare_threshold=0 is set on that connection.\n\nThis issue affects pgAdmin 4: from 9.13 before 9.17.","modified":"2026-08-02T03:47:42.871974072Z","published":"2026-07-31T16:00:19.103Z","database_specific":{"unresolved_ranges":[{"source":"AFFECTED_FIELD","extracted_events":[{"introduced":"9.13"},{"fixed":"9.17"}]},{"source":"DESCRIPTION","extracted_events":[{"introduced":"9.13"},{"fixed":"9.17"}]}],"cna_assigner":"PostgreSQL","cwe_ids":["CWE-115","CWE-89"],"osv_generated_from":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/17xxx/CVE-2026-17351.json"},"references":[{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/17xxx/CVE-2026-17351.json"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-17351"},{"type":"REPORT","url":"https://github.com/pgadmin-org/pgadmin4/issues/10192"},{"type":"FIX","url":"https://github.com/pgadmin-org/pgadmin4/commit/bf4792444446f0e7ab721d23cbd6bfe6afaa7a8b"},{"type":"FIX","url":"https://github.com/pgadmin-org/pgadmin4/commit/ef76102bcd1cdb544eb9b4ef18d3382f22b76752"},{"type":"PACKAGE","url":"https://github.com/pgadmin-org/pgadmin4"}],"affected":[{"ranges":[{"type":"GIT","repo":"https://github.com/pgadmin-org/pgadmin4","events":[{"introduced":"0"},{"fixed":"bf4792444446f0e7ab721d23cbd6bfe6afaa7a8b"},{"fixed":"ef76102bcd1cdb544eb9b4ef18d3382f22b76752"}],"database_specific":{"source":"REFERENCES"}}],"versions":["REL-9_16","REL-9_15","REL-9_14","REL-9_13","REL-9_12","REL-9_11","REL-9_10","REL-9_9","REL-9_8","REL-9_7","REL-9_6","REL-9_5","REL-9_4","REL-9_3","REL-9_2","REL-9_1","REL-9_0","REL-8_14","REL-8_13","REL-8_12","REL-8_11","REL-8_10","REL-8_9","REL-8_8","REL-8_7","REL-8_6","REL-8_5","REL-8_4","REL-8_3","REL-8_2","REL-8_1","REL-8_0","REL-7_8","REL-7_7","REL-7_6","REL-7_5","REL-7_4","REL-7_3","REL-7_2","REL-7_1","REL-7_0","REL-6_21","REL-6_20","REL-6_19","REL-6_18","REL-6_17","REL-6_16","REL-6_15","REL-6_14","REL-6_13","REL-6_12","REL-6_11","REL-6_10","REL-6_9","REL-6_8","REL-6_7","REL-6_6","REL-6_5","REL-6_4","REL-6_3","REL-6_2","REL-6_1","REL-6_0","REL-5_7","REL-5_6","REL-5_5","REL-5_4","REL-5_3","REL-5_2","REL-5_1","REL-5_0","REL-4_30","REL-4_29","REL-4_28","REL-4_27","REL-4_26","REL-4_25","REL-4_24","REL-4_23","REL-4_22","REL-4_21","REL-4_20","REL-4_19","REL-4_18","REL-4_17","REL-4_16","REL-4_15","REL-4_14","REL-4_13","REL-4_12","REL-4_11","REL-4_10","REL-4_9","REL-4_8","REL-4_7","REL-4_6","REL-4_5","REL-4_4","REL-4_3","REL-4_2","REL-4_1","REL-4_0","REL-3_6","REL-3_5","REL-3_4","REL-3_3","REL-3_2","REL-3_1","REL-3_0","REL-2_1","REL-2_0","REL-2_0-RC2","REL-2_0-RC1","REL-1_6","REL-1_5","REL-1_4","REL-1_3","REL-1_2","REL-1_1","REL-1_0","REL-1_0-RC1","REL-1_0-BETA4","REL-1_0-BETA3","REL-1_0-BETA2","REL-1_0-BETA1"],"database_specific":{"source":"https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-17351.json"}}],"schema_version":"1.7.5","severity":[{"type":"CVSS_V4","score":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H"}]}