CVE-2026-17351 is a critical (CVSS 9.0) flaw in pgAdmin 4 versions 9.13 up to but not including 9.17. A query check and PostgreSQL parse quotes differently, so the AI Assistant read-only guard can be bypassed. The fix is pgAdmin 4 9.17, released on 30 July 2026.
What's affected
pgAdmin 4 from 9.13 up to, but not including, 9.17. The pgAdmin maintainers fixed it in 9.17 with commit ef76102, and the issue notes state that 9.17 was released on 30 July 2026.
This CVE is an incomplete fix for CVE-2026-12045, which was addressed in 9.16. The earlier fix required that the query the AI Assistant runs parses as exactly one statement that is not a transaction control statement, and that it runs inside a read-only transaction. The new issue shows that check could be fooled. An earlier candidate patch also did not work on default settings, which is why the final fix is a different one.
How to check if you're exposed
Find the pgAdmin version. In the web interface, open the About pgAdmin dialog from the Help menu. For a Python install you can also check the package.
pip show pgadmin4
For container deployments, check the image tag. Then check whether the AI Assistant is enabled and a language model provider is configured. The advisory says the attack is delivered by indirect prompt injection, where an attacker plants text in a database object that the assistant may read, so servers that connect the assistant to shared or untrusted data are most at risk.
What to do now
- Find every pgAdmin 4 instance, including desktop installs, containers and shared web deployments.
- Upgrade to 9.17 or later, and confirm the version afterward.
- Until you can upgrade, avoid using the AI Assistant against servers where the database role can write. The advisory lists no workaround, so treat this as a precaution.
- Give the role the assistant connects with only the rights it needs, ideally read access only.
- Check the database for unexpected new tables or objects created since 9.13.
Why it matters
The weaknesses are CWE-115 (Misinterpretation of Input), CWE-89 (SQL Injection). The read-only guard used the sqlparse library to decide whether a query was a single safe statement, then ran it inside a read-only transaction. Under PostgreSQL's default setting for standard_conforming_strings, a backslash before a quote is an ordinary character for PostgreSQL, but sqlparse treats it as an escape. The two parsers can therefore disagree about where a string ends, so something sqlparse sees as one statement can run as several. The extra statements can end the read-only transaction, after which writes succeed.
The fix runs the query over the extended query protocol, so PostgreSQL's own parser rejects multi-statement text no matter how a client-side lexer classifies it. The general lesson is that a filter and the thing it protects must parse input the same way. CISA does not list this CVE as known exploited, and the pages we read report no exploitation.
Try it yourself
Parser disagreements like this live in code. This demo shows how a code scan reports a risky pattern and where it points.
Click through it at your own pace, or open it full screen.
Quick check
Is this the same as CVE-2026-12045?
It is related. The maintainers describe it as an incomplete fix for CVE-2026-12045, so the same attack goal was reachable another way until 9.17.
Does the attacker need to talk to the AI Assistant directly?
The advisory describes indirect prompt injection: the attacker plants a payload in an object the assistant may read, and the model then emits it as a tool call.
Sources
Last reviewed: 19 October 2026.
