https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 11:20:44 +0000 https://cve.radiocsirt.org/vuln/cve-2026-17351 <p><strong>Affected:</strong> pgadmin.org pgAdmin 4</p> <p>The fix for CVE-2026-12045 in pgAdmin 4 9.16 required the LLM-supplied query passed to the AI Assistant&#39;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&#39;s string-literal lexing can disagree with PostgreSQL&#39;s own parser: under standard_conforming_strings = on (PostgreSQL&#39;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 &#39;\&#39;;COMMIT;CREATE TABLE pwn(x int);SELECT 1 --&#39; therefore parses as a single SELECT to sqlparse&#39;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).</p> <p>An initial candidate fix ran the query with psycopg&#39;s execute(..., prepare=True), intending to force PostgreSQL&#39;s own Parse step (extended query protocol) to reject multi-statement text regardless of sqlparse&#39;s classification. This candidate fix does not work as submitted: psycopg3&#39;s PrepareManager silently ignores the prepare argument whenever the connection&#39;s prepare_threshold is None, which is pgAdmin&#39;s default for every…</p> <p><strong>Affected:</strong> pgadmin.org pgAdmin 4</p> <p>The fix for CVE-2026-12045 in pgAdmin 4 9.16 required the LLM-supplied query passed to the AI Assistant&#39;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&#39;s string-literal lexing can disagree with PostgreSQL&#39;s own parser: under standard_conforming_strings = on (PostgreSQL&#39;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 &#39;\&#39;;COMMIT;CREATE TABLE pwn(x int);SELECT 1 --&#39; therefore parses as a single SELECT to sqlparse&#39;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).</p> <p>An initial candidate fix ran the query with psycopg&#39;s execute(..., prepare=True), intending to force PostgreSQL&#39;s own Parse step (extended query protocol) to reject multi-statement text regardless of sqlparse&#39;s classification. This candidate fix does not work as submitted: psycopg3&#39;s PrepareManager silently ignores the prepare argument whenever the connection&#39;s prepare_threshold is None, which is pgAdmin&#39;s default for every…</p> https://cve.radiocsirt.org/vuln/cve-2026-17351