Skip to content
Connect AISign inSign up free
CVE-2026-173519.0CriticalCWE-89

CVE-2026-17351: pgAdmin 4: AI Assistant read-only transaction bypass via sqlparse/PostgreSQL lexer disagreement (incomplete fix for CVE-2026-12045)

pgadmin.org · pgAdmin 4

Fixed in 9.17 · Affected: pgadmin.org pgAdmin 4 before 9.17 · Exploitation: unlikely (under 1%)

Not in CyberSIXT coverage yet: no article names this CVE. This page shows the public record.

0.5%probability of exploitation in the next 30 days
42nd percentile
050100

Higher than 42% of scored CVEs

9.0CriticalCVSS 3.1
LowCrit.

DescriptionCVE.org

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). An 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.

Affected products1

From the CVE record. A product or version that is not listed is unknown, not unaffected.

  • pgadmin.org · pgAdmin 4from 9.13 before 9.17

On the Atlas

Every published CVE is on the CyberSIXT Atlas, grouped by weakness, vendor and month.

Open the Atlas
Exploitation
Unlikely (under 1%). EPSS under 1%, or no score yet.
CISA KEV
Not listed
Public check
No public nuclei template
Published
July 2026

CoverageNo articles yet

No CyberSIXT article names CVE-2026-17351 yet, so there is no coverage timeline, action brief or change log for it. Everything on this page comes from the public CVE record, CISA KEV, EPSS and the nuclei template index. Search the archive or see the CVEs in the news.

References