Description
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 execute_sql_query 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 pg_execute_server_program, 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.
Threat model: indirect prompt injection. An attacker with low-privilege DB write access plants a payload in any object the AI Assistant might read (table row, column value, comment). When a pgAdmin user with a higher-privilege role (typically PostgreSQL superuser or holder of pg_execute_server_program) opens the AI Assistant against that content, the LLM emits the multi-statement payload as a tool call. The crafted payload uses COMMIT / END / ROLLBACK / ABORT to close the wrapping read-only transaction, then COPY ... TO PROGRAM to gain OS code execution on the DB host. S:C is earned by the confused-deputy pattern: the attacker is not the LLM user; third-party DB content steers the user's LLM session to execute writes the user did not authorise. This does *not* score the user self-jailbreaking their own assistant -- only the indirect-injection vector. Alternative: AC:H (-> 8.0 HIGH) is defensible given LLM non-determinism (the payload doesn't fire every invocation) and the superuser-victim precondition. The 9.0 figure is the optimistic end of the range.
Same reasoning as the CVSS 3.1 entry: indirect prompt injection, third-party content drives the user's LLM session, COPY ... TO PROGRAM reaches the DB host. VC:H/VI:H/VA:H + SC:H/SI:H/SA:H since RCE on the DB host compromises both pgAdmin's authority and the downstream system. UI:P captures that the user merely uses the AI Assistant normally; the attacker does not direct any specific user action.
Problem types
CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
CWE-77 Improper Neutralization of Special Elements used in a Command ('Command Injection')
Product status
9.13 (custom) before 9.16
Credits
Isaac Chen <isaac9503@gmail.com>
Dave Page <page@pgadmin.org>
Kundan Sable <kundan.sable@enterprisedb.com>
References
github.com/pgadmin-org/pgadmin4/issues/10022
github.com/...ommit/bf4792444446f0e7ab721d23cbd6bfe6afaa7a8b