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.
Published: 2026-07-31
Score: 9.4 Critical
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The issue arises from a mismatch between PostgreSQL and the sqlparse library used by the AI Assistant's execute_sql_query tool. The victim's SQL string can be parsed by sqlparse as a single, harmless statement but is interpreted by PostgreSQL as a series of statements, including a COMMIT that exits the read‑only wrapper and a subsequent CREATE TABLE. The attacker can therefore inject write operations into a supposedly read‑only session and, by creating privileged objects, achieve remote code execution. This vulnerability corresponds to the CWE‑115 and CWE‑89 classes.

Affected Systems

The flaw appears in pgAdmin 4 version 9.13, 9.14, 9.15 and 9.16 released by pgadmin.org. The bug is triggered when the AI Assistant feature reads any object and the LLM emits a tool call containing the payload. These versions are affected until the release of pgAdmin 4 9.17, which deploys a patch that forces the connection to use the extended query protocol with prepare_threshold set to zero.

Risk and Exploitability

The CVSS score of 9.4 indicates critical severity. EPSS is below 1 %, suggesting that, while the flaw is hardly used in the wild, any discovered instance would be highly damaging. It is not listed in the CISA KEV catalog, so no known exploitation campaigns have been reported yet. Nevertheless, the attack vector requires only the ability to pose a prompt to the AI Assistant, a permission many users already grant. The toxicity of the bypass (write operations evolve to create tables) makes this a high‑risk vulnerability that should be patched immediately or mitigated by disabling or restricting the AI Assistant.

Generated by OpenCVE AI on August 2, 2026 at 04:07 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade pgAdmin 4 to the latest version (9.17 or newer) to receive the corrected fetch and parsing logic.
  • Disable or restrict the AI Assistant feature until a patch can be applied, preventing the tool from executing arbitrary SQL.
  • Enable detailed logging for AI Assistant SQL executions and review entries for multi‑statement commands that could indicate exploitation attempts.

Generated by OpenCVE AI on August 2, 2026 at 04:07 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sun, 02 Aug 2026 19:30:00 +0000

Type Values Removed Values Added
First Time appeared Pgadmin
Pgadmin pgadmin 4
Vendors & Products Pgadmin
Pgadmin pgadmin 4

Fri, 31 Jul 2026 17:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}

Fri, 31 Jul 2026 16:15:00 +0000

Type Values Removed Values Added
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.
Title pgAdmin 4: AI Assistant read-only transaction bypass via sqlparse/PostgreSQL lexer disagreement (incomplete fix for CVE-2026-12045)
Weaknesses CWE-115
CWE-89
References
Metrics cvssV3_1

{'score': 9, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H'}

cvssV4_0

{'score': 9.4, 'vector': 'CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H'}

Subscriptions

Pgadmin Pgadmin 4
cve-icon MITRE

Status: PUBLISHED

Assigner: PostgreSQL

Published:

Updated: 2026-08-01T03:56:14.973Z

Reserved: 2026-07-25T02:52:57.350Z

Link: CVE-2026-17351

cve-icon Vulnrichment

Updated: 2026-07-31T17:00:14.067Z

cve-icon NVD

Status : Analyzed

Published: 2026-07-31T16:16:59.807

Modified: 2026-08-05T20:07:14.527

Link: CVE-2026-17351

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

Updated: 2026-08-02T19:15:17Z

Weaknesses
  • CWE-115

    Misinterpretation of Input

  • CWE-89

    Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')