Summary
A SQL injection flaw in pgAdmin 4's AI Assistant allows carefully crafted, LLM-supplied queries to bypass read-only transaction safeguards and execute multiple SQL statements.
When sqlparse's validation disagrees with PostgreSQL's own parsing, an attacker can smuggle write operations or more dangerous commands through what appears to be a single safe SELECT, making AI-driven database interactions risky wherever the assistant can read attacker-controlled content.
Affected context
This vulnerability arises in pgAdmin 4's AI Assistant feature when it executes LLM-generated SQL against PostgreSQL using sqlparse-based validation and the simple query protocol.
It is relevant in environments where:
- The AI Assistant is enabled and allowed to run SQL against live databases
- The assistant can consume prompts or data from objects that may contain attacker-controlled content (e.g., comments, table data, saved queries)
- PostgreSQL runs with standard_conforming_strings = on (the default) and pgAdmin uses psycopg3 with the prepare_threshold unset on server connections
Exploit preconditions
- Attack surface: The AI Assistant's execute_sql_query tool in pgAdmin 4, reachable via LLM-generated tool calls.
- Required access: Ability to influence content that the AI Assistant may read or be prompted with (such as database fields, comments, documents, or shared query text).
- Trigger point: The assistant sends a crafted SQL string that sqlparse misclassifies as a single non-transaction-control statement, which pgAdmin then runs inside a nominal read-only transaction using the simple query protocol.
- Why exploitation is possible: sqlparse's string-literal handling can diverge from PostgreSQL's parser, allowing multi-statement payloads to be parsed as a single SELECT by the validator while PostgreSQL executes multiple commands; the lack of enforced extended query protocol means PostgreSQL still accepts multi-statement text.
Why this happens
The underlying issue combines a classic SQL injection pattern with parser mismatch and protocol misuse.
pgAdmin relies on sqlparse to confirm that an LLM-supplied query is exactly one non-transaction-control statement before wrapping it in a BEGIN TRANSACTION READ ONLY block.
However, sqlparse's interpretation of backslashes in string literals differs from PostgreSQL under standard_conforming_strings, so a payload can embed additional commands (like COMMIT; CREATE TABLE ...) that sqlparse treats as part of a single SELECT.
Because psycopg3 defaults to the simple query protocol when prepare_threshold is None, the database accepts and executes multi-statement text despite the validator.
This maps to CWE-89 (Improper Neutralization of Special Elements used in an SQL Command) and CWE-115 (Misinterpretation of Input), where validation is performed against one parsing model while execution uses another.
Potential impact
- Attackers may cause write operations (INSERT/UPDATE/DELETE) against supposedly read-only connections.
- Attackers could create or alter tables, functions, or other database objects.
- Attackers can potentially chain SQL features into remote code execution paths in environments where database-level code execution primitives exist.
- Attackers may bypass safeguards designed to prevent destructive actions from AI-generated queries.
- Attackers could poison data used by downstream applications or analytics.
General mitigation guidance
Mitigation focuses on ensuring that query validation and execution semantics are aligned and that multi-statement text cannot slip past safety checks.
Defenders can:
- Prefer server-enforced mechanisms (such as the extended query protocol with prepared statements) that structurally reject multi-statement input rather than relying solely on client-side SQL parsing.
- Treat LLM-supplied queries as untrusted input, applying strict constraints on allowed statement types and disallowing transaction control, data definition, and potentially dangerous procedural constructs.
- Isolate AI-driven query execution to dedicated read-only connections with minimized privileges and explicit protocol settings that favor safety over performance.
- Reduce trust in any user- or data-originated content that may be fed into AI prompts, and consider explicit allowlists for SQL operations the assistant is permitted to perform.
How teams detect issues like this
Detection typically involves examining both code paths and runtime behavior around AI-assisted query execution.
Organizations can:
- Use static analysis or targeted code review to flag client-side SQL validation that depends on third-party parsers without enforcing matching execution semantics (e.g., reliance on sqlparse while still using the simple query protocol).
- Look for application logic that claims to run in "read-only transactions" but still uses multi-statement-capable execution modes or does not enforce prepared statements.
- Instrument database logging to detect multi-statement queries arriving from AI Assistant connections, including unexpected COMMIT, CREATE, or other write operations coming from read-only tooling.
- Apply automated policy enforcement that rejects changes introducing AI features capable of issuing unconstrained SQL or that weaken protocol-level safeguards on privileged connections.
