{"api_version":"1","generated_at":"2026-07-31T20:52:19+00:00","cve":"CVE-2026-17351","urls":{"html":"https://cve.report/CVE-2026-17351","api":"https://cve.report/api/cve/CVE-2026-17351.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-17351","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-17351"},"summary":{"title":"pgAdmin 4: AI Assistant read-only transaction bypass via sqlparse/PostgreSQL lexer disagreement (incomplete fix for CVE-2026-12045)","description":"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.","state":"PUBLISHED","assigner":"PostgreSQL","published_at":"2026-07-31 16:16:59","updated_at":"2026-07-31 18:17:11"},"problem_types":["CWE-89","CWE-115","CWE-89 CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')","CWE-115 CWE-115 Misinterpretation of Input"],"metrics":[{"version":"4.0","source":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","type":"Secondary","score":"9.4","severity":"CRITICAL","vector":"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","data":{"version":"4.0","vectorString":"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","baseScore":9.4,"baseSeverity":"CRITICAL","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"NONE","privilegesRequired":"LOW","userInteraction":"PASSIVE","vulnConfidentialityImpact":"HIGH","vulnIntegrityImpact":"HIGH","vulnAvailabilityImpact":"HIGH","subConfidentialityImpact":"HIGH","subIntegrityImpact":"HIGH","subAvailabilityImpact":"HIGH","exploitMaturity":"NOT_DEFINED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"NOT_DEFINED"}},{"version":"4.0","source":"CNA","type":"CVSS","score":"9.4","severity":"CRITICAL","vector":"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","data":{"baseScore":9.4,"baseSeverity":"CRITICAL","vectorString":"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","version":"4.0"}},{"version":"3.1","source":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","type":"Secondary","score":"9","severity":"CRITICAL","vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H","baseScore":9,"baseSeverity":"CRITICAL","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"REQUIRED","scope":"CHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"CVSS","score":"9","severity":"CRITICAL","vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H","data":{"attackComplexity":"LOW","attackVector":"NETWORK","availabilityImpact":"HIGH","baseScore":9,"baseSeverity":"CRITICAL","confidentialityImpact":"HIGH","integrityImpact":"HIGH","privilegesRequired":"LOW","scope":"CHANGED","userInteraction":"REQUIRED","vectorString":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H","version":"3.1"}}],"references":[{"url":"https://github.com/pgadmin-org/pgadmin4/commit/bf4792444446f0e7ab721d23cbd6bfe6afaa7a8b","name":"https://github.com/pgadmin-org/pgadmin4/commit/bf4792444446f0e7ab721d23cbd6bfe6afaa7a8b","refsource":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/pgadmin-org/pgadmin4/issues/10192","name":"https://github.com/pgadmin-org/pgadmin4/issues/10192","refsource":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/pgadmin-org/pgadmin4/commit/ef76102bcd1cdb544eb9b4ef18d3382f22b76752","name":"https://github.com/pgadmin-org/pgadmin4/commit/ef76102bcd1cdb544eb9b4ef18d3382f22b76752","refsource":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-17351","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-17351","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"pgadmin.org","product":"pgAdmin 4","version":"affected 9.13 9.17 custom","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[{"source":"CNA","value":"Kai Aizen (SnailSploit)","lang":"en"},{"source":"CNA","value":"Kundan Sable <kundan.sable@enterprisedb.com>","lang":"en"},{"source":"CNA","value":"Ashesh Vashi <ashesh.vashi@enterprisedb.com>","lang":"en"},{"source":"CNA","value":"Ashesh Vashi <ashesh.vashi@enterprisedb.com>","lang":"en"}],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"adp":[{"metrics":[{"other":{"content":{"id":"CVE-2026-17351","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"total"}],"role":"CISA Coordinator","timestamp":"2026-07-31T17:00:07.232339Z","version":"2.0.3"},"type":"ssvc"}}],"providerMetadata":{"dateUpdated":"2026-07-31T17:00:18.211Z","orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","shortName":"CISA-ADP"},"title":"CISA ADP Vulnrichment"}],"cna":{"affected":[{"defaultStatus":"unaffected","modules":["AI Assistant","LLM Tools"],"product":"pgAdmin 4","programFiles":["https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/llm/tools/database.py"],"repo":"https://github.com/pgadmin-org/pgadmin4","vendor":"pgadmin.org","versions":[{"lessThan":"9.17","status":"affected","version":"9.13","versionType":"custom"}]}],"credits":[{"lang":"en","type":"finder","value":"Kai Aizen (SnailSploit)"},{"lang":"en","type":"remediation developer","value":"Kundan Sable <kundan.sable@enterprisedb.com>"},{"lang":"en","type":"remediation developer","value":"Ashesh Vashi <ashesh.vashi@enterprisedb.com>"},{"lang":"en","type":"remediation reviewer","value":"Ashesh Vashi <ashesh.vashi@enterprisedb.com>"}],"descriptions":[{"lang":"en","value":"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."}],"metrics":[{"cvssV3_1":{"attackComplexity":"LOW","attackVector":"NETWORK","availabilityImpact":"HIGH","baseScore":9,"baseSeverity":"CRITICAL","confidentialityImpact":"HIGH","integrityImpact":"HIGH","privilegesRequired":"LOW","scope":"CHANGED","userInteraction":"REQUIRED","vectorString":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H","version":"3.1"},"format":"CVSS","scenarios":[{"lang":"en","value":"Threat model: identical to CVE-2026-12045 -- indirect prompt injection. An attacker with low-privilege DB write access plants a payload in any object the AI Assistant might read (table row, column value, comment). When a pgAdmin user with a higher-privilege database role (typically superuser or holder of pg_execute_server_program) opens the AI Assistant against that content, the LLM emits the lexer-differential payload as a tool call, which smuggles a COMMIT past the intended read-only guard and can chain to COPY ... TO PROGRAM for OS code execution. Scored identically to the original CVE-2026-12045 record for consistency, since this is the same vulnerability surviving an incomplete fix rather than a functionally different bug: S:C for the confused-deputy pattern (attacker is not the LLM user; third-party DB content steers the user's own LLM session into unauthorised writes)."}]},{"cvssV4_0":{"baseScore":9.4,"baseSeverity":"CRITICAL","vectorString":"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","version":"4.0"},"format":"CVSS","scenarios":[{"lang":"en","value":"Same reasoning as the CVSS 3.1 entry and as the original CVE-2026-12045 record: indirect prompt injection, third-party content drives the user's LLM session, COPY ... TO PROGRAM reaches the DB host. VC:H/VI:H/VA:H + SC:H/SI:H/SA:H since RCE on the DB host compromises both pgAdmin's authority and the downstream system. UI:P captures that the user merely uses the AI Assistant normally."}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-89","description":"CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')","lang":"en","type":"CWE"},{"cweId":"CWE-115","description":"CWE-115 Misinterpretation of Input","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-07-31T16:00:19.103Z","orgId":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","shortName":"PostgreSQL"},"references":[{"tags":["issue-tracking"],"url":"https://github.com/pgadmin-org/pgadmin4/issues/10192"},{"tags":["patch"],"url":"https://github.com/pgadmin-org/pgadmin4/commit/ef76102bcd1cdb544eb9b4ef18d3382f22b76752"},{"tags":["related"],"url":"https://github.com/pgadmin-org/pgadmin4/commit/bf4792444446f0e7ab721d23cbd6bfe6afaa7a8b"}],"source":{"discovery":"EXTERNAL"},"title":"pgAdmin 4: AI Assistant read-only transaction bypass via sqlparse/PostgreSQL lexer disagreement (incomplete fix for CVE-2026-12045)"}},"cveMetadata":{"assignerOrgId":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","assignerShortName":"PostgreSQL","cveId":"CVE-2026-17351","datePublished":"2026-07-31T16:00:19.103Z","dateReserved":"2026-07-25T02:52:57.350Z","dateUpdated":"2026-07-31T17:00:18.211Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-07-31 16:16:59","lastModifiedDate":"2026-07-31 18:17:11","problem_types":["CWE-89","CWE-115","CWE-89 CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')","CWE-115 CWE-115 Misinterpretation of Input"],"metrics":{"cvssMetricV40":[{"source":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","type":"Secondary","cvssData":{"version":"4.0","vectorString":"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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","baseScore":9.4,"baseSeverity":"CRITICAL","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"NONE","privilegesRequired":"LOW","userInteraction":"PASSIVE","vulnConfidentialityImpact":"HIGH","vulnIntegrityImpact":"HIGH","vulnAvailabilityImpact":"HIGH","subConfidentialityImpact":"HIGH","subIntegrityImpact":"HIGH","subAvailabilityImpact":"HIGH","exploitMaturity":"NOT_DEFINED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"NOT_DEFINED"}}],"cvssMetricV31":[{"source":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H","baseScore":9,"baseSeverity":"CRITICAL","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"REQUIRED","scope":"CHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":2.3,"impactScore":6}],"ssvcV203":[{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","ssvcData":{"timestamp":"2026-07-31T17:00:07.232339Z","id":"CVE-2026-17351","options":[{"exploitation":"none"},{"automatable":"no"},{"technicalImpact":"total"}],"role":"CISA Coordinator","version":"2.0.3"}}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"17351","Ordinal":"1","Title":"pgAdmin 4: AI Assistant read-only transaction bypass via sqlpars","CVE":"CVE-2026-17351","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"17351","Ordinal":"1","NoteData":"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.","Type":"Description","Title":"pgAdmin 4: AI Assistant read-only transaction bypass via sqlpars"}]}}}