CVE-2026-17351 SQL injection in pgAdmin 4

Critical 9.4 Published 31 Jul 2026 Updated 1 Aug 2026

Attackers can bypass read-only transaction restrictions in pgAdmin 4's AI Assistant via SQL injection, enabling arbitrary code execution and data modification.

Exploited in the wild: Not known
Login needed: Any signed-in user
Attackable: Over the internet
Victim action needed: A user has to click or open something
Fix: Available

What is CVE-2026-17351?

CVE-2026-17351 is a critical SQL injection vulnerability in pgadmin.org pgAdmin 4, published on 31 Jul 2026. Any signed-in user can exploit it over the network, and only if a user opens a file or follows a link.

Official 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.

Weakness: CWE-89, CWE-115

Which versions are affected by CVE-2026-17351?

It affects 1 product.

Products include Pgadmin Pgadmin 4.

How do I fix CVE-2026-17351?

Apply the vendor's patch.

Use parameterised queries everywhere and never build SQL by joining strings. Upgrade affected software first; a web application firewall only buys time. More about SQL injection.

Is CVE-2026-17351 being exploited?

There is no known exploitation of CVE-2026-17351 in the wild and no public exploit code.

Public exploit code: 1 proofs of concept on GitHub.

Sources

Also known as GHSA-v5gm-27gp-4f7w.