Skip to main content
VulnerabilityPublished

CVE-2026-17351: pgAdmin 4 · SQL Injection

Affects pgAdmin 4Source CVE Database V5

0
Compare

Mentioned vulnerabilities

Not known to be exploited · CVSS 9.0 Critical : upgrade to 9.17 as a priority.

Data as of 30 Oct 2026, 06:59 UTC

CVSS 3.1 base score
9.0Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.4% chance of exploitation in 30 days – higher than 41% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 9.17
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 31 Jul 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: evidence found.

    Public exploit code: GitHub proofs of concept

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), GitHub proofs of concept, the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.

What to do

Upgrade pgAdmin 4 to 9.17.

Affected software

ProductAffectedFixed in
pgadmin.orgpgAdmin 4Affected
  • >=9.13 <9.17
Fixed in
  • 9.17
GitHubpgAdmin 4pkg:github/pgAdmin 4Other threatsAffected
  • >=9.13 <9.17
Fixed in
  • 9.17

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

The initial fix attempt was ineffective due to default psycopg3 connection settings. The corrected fix requires setting conn.prepare_threshold=0 on the AI Assistant's dedicated database connection to enforce the extended query protocol and prevent multi-statement execution. Administrators should monitor pgAdmin 4 updates and apply official patches once released. Until then, consider restricting or disabling the AI Assistant's execute_sql_query tool if feasible.

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). 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. The 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. This issue affects pgAdmin 4: from 9.13 before 9.17.

References

Community reviews

Loading reviews…