CVE-2026-12045: pgAdmin 4: AI Assistant read-only transaction bypass allows unauthorised writes and remote code execution
Read-only transaction bypass in the pgAdmin 4 AI Assistant allows an attacker who can influence database content that the assistant reads to execute arbitrary SQL with the privileges of the pgAdmin user's database role.
The AI Assistant's executesqlquery tool runs LLM-generated SQL inside a BEGIN TRANSACTION READ ONLY wrapper to prevent data modification. The LLM-supplied query was forwarded to the database driver without restriction to a single statement or to read-only verbs, so a multi-statement payload beginning with COMMIT, END, ROLLBACK, or ABORT terminated the read-only transaction and ran subsequent statements in autocommit mode. The trailing ROLLBACK then had no effect.
Delivery is via prompt injection: an attacker who can write content into any object the AI Assistant may inspect (a row, a column value, a comment) can cause the LLM to emit the multi-statement payload as a tool call. With ordinary write privileges on the pgAdmin user's role the attacker can perform unauthorised data modification. When the pgAdmin user's role is a PostgreSQL superuser or holds pgexecuteserverprogram, the chain extends to remote code execution on the database server host via COPY ... TO PROGRAM.
Fix validates the LLM-supplied query up front: it must parse to exactly one non-empty / non-comment statement whose leading real token (after stripping whitespace, comments, and punctuation) is one of SELECT, WITH, EXPLAIN, SHOW, VALUES, or TABLE. Transaction-control verbs, DML, DDL, CALL, COPY, DO, SET/RESET, and everything else are rejected before any database work happens. PostgreSQL's READ ONLY mode continues to backstop data-modifying CTEs, EXPLAIN ANALYZE on writes, and volatile side effects.
This issue affects pgAdmin 4: from 9.13 before 9.16.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pgAdmin 4to a version that resolves this vulnerability.Fixed in 9.16 - Configuration
Validate the LLM-supplied SQL up front before calling the database driver: parse to exactly one non-empty/non-comment statement, and reject anything whose leading real token (after stripping whitespace/comments/punctuation) is not one of SELECT, WITH, EXPLAIN, SHOW, VALUES, or TABLE.
pgAdmin 4 AI Assistant (execute_sql_query) LLM-generated SQL validation = exactly one non-empty / non-comment statement; leading real token must be one of SELECT, WITH, EXPLAIN, SHOW, VALUES, TABLE - Compensating control
Keep the SQL execution inside a BEGIN TRANSACTION READ ONLY wrapper and ensure the wrapper cannot be terminated by LLM-supplied multi-statement payloads (e.g., reject multi-statement input entirely and disallow transaction-control verbs like COMMIT/END/ROLLBACK/ABORT before any database work happens).
- Compensating control
Use least privilege for the pgAdmin database role running the AI Assistant: avoid superuser privileges and avoid granting pg_execute_server_program, as the bypass chain can extend to remote code execution via COPY when those privileges are present.
Event History
Frequently Asked Questions
What is the severity of CVE-2026-12045?
The severity of CVE-2026-12045 is rated as critical with a score of 9.
How do I fix CVE-2026-12045?
To fix CVE-2026-12045, update pgAdmin 4 to the latest version that addresses the vulnerability.
What type of attacks does CVE-2026-12045 enable?
CVE-2026-12045 enables unauthorized writes and remote code execution through a read-only transaction bypass.
Who is affected by CVE-2026-12045?
Users of pgAdmin 4 with AI Assistant capabilities are affected by CVE-2026-12045.
Can CVE-2026-12045 lead to database compromise?
Yes, CVE-2026-12045 can lead to database compromise as it allows execution of arbitrary SQL with the privileges of the pgAdmin user.