https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 16:27:07 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-15270 bdu:2026-15270 https://cve.radiocsirt.org/vuln/bdu:2026-15270 https://cve.radiocsirt.org/vuln/euvd-2026-343571 EUVD-2026-343571 https://cve.radiocsirt.org/vuln/euvd-2026-343571 https://cve.radiocsirt.org/vuln/fkie_cve-2026-17351 <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>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/fkie_cve-2026-17351 https://cve.radiocsirt.org/vuln/ghsa-v5gm-27gp-4f7w <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>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/ghsa-v5gm-27gp-4f7w https://cve.radiocsirt.org/vuln/opensuse-su-2026:11508-1 <p>pgadmin4-9.17-1.1 on GA media</p> <p>pgadmin4-9.17-1.1 on GA media</p> https://cve.radiocsirt.org/vuln/opensuse-su-2026:11508-1 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2613 <p>Ein Angreifer kann mehrere Schwachstellen in pgAdmin ausnutzen, um beliebigen Programmcode auszuführen, SQL-Injection-Angriffe durchzuführen, Sicherheitsmaßnahmen zu umgehen, vertrauliche Informationen offenzulegen und Daten zu manipulieren.</p> <p>Ein Angreifer kann mehrere Schwachstellen in pgAdmin ausnutzen, um beliebigen Programmcode auszuführen, SQL-Injection-Angriffe durchzuführen, Sicherheitsmaßnahmen zu umgehen, vertrauliche Informationen offenzulegen und Daten zu manipulieren.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2613