https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 15:32:43 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-11412 bdu:2026-11412 https://cve.radiocsirt.org/vuln/bdu:2026-11412 https://cve.radiocsirt.org/vuln/euvd-2026-343570 EUVD-2026-343570 https://cve.radiocsirt.org/vuln/euvd-2026-343570 https://cve.radiocsirt.org/vuln/fkie_cve-2026-17566 <p>pgAdmin 4&#39;s Import/Export Data tool builds a psql \copy (...) command line by interpolating a user-supplied SQL query into a Jinja template and passing the rendered line to psql via --command. To stop an attacker from breaking out of the (...) wrapper, create_import_export_job() (route POST /import_export/job/&lt;sid&gt;, gated only by the ordinary, commonly-granted tools_import_export_data permission) validated the query with a hand-written parenthesis-balance checker, _is_query_parens_balanced(). That checker always treated a backslash before a single quote (\&#39;) as escaping the quote, i.e. as if standard_conforming_strings were off. PostgreSQL has defaulted standard_conforming_strings to on since 9.1 (2010), the default on every PostgreSQL version pgAdmin 4 currently supports (13-18); under that default psql&#39;s own \copy tokenizer treats \ as an ordinary character, so a single quote immediately after it closes the string literal. A query such as SELECT &#39;a\&#39;) TO PROGRAM &#39;echo pwned&#39; x&#39; was therefore accepted as &#34;balanced&#34; by pgAdmin&#39;s checker (which believed the ) was still inside the string), while psql, run through the actual rendered command line, closes the string at that point and treats the following ) as the end of the wrapping \copy (...) subquery, exposing an attacker-chosen TO PROGRAM &#39;&lt;command&gt;&#39; clause that psql executes via popen() -- independent of a subsequent syntax error later on the same line. This is the same class of bug as CVE-2025-12762/CVE-2025-13780 (RCE via…</p> <p>pgAdmin 4&#39;s Import/Export Data tool builds a psql \copy (...) command line by interpolating a user-supplied SQL query into a Jinja template and passing the rendered line to psql via --command. To stop an attacker from breaking out of the (...) wrapper, create_import_export_job() (route POST /import_export/job/&lt;sid&gt;, gated only by the ordinary, commonly-granted tools_import_export_data permission) validated the query with a hand-written parenthesis-balance checker, _is_query_parens_balanced(). That checker always treated a backslash before a single quote (\&#39;) as escaping the quote, i.e. as if standard_conforming_strings were off. PostgreSQL has defaulted standard_conforming_strings to on since 9.1 (2010), the default on every PostgreSQL version pgAdmin 4 currently supports (13-18); under that default psql&#39;s own \copy tokenizer treats \ as an ordinary character, so a single quote immediately after it closes the string literal. A query such as SELECT &#39;a\&#39;) TO PROGRAM &#39;echo pwned&#39; x&#39; was therefore accepted as &#34;balanced&#34; by pgAdmin&#39;s checker (which believed the ) was still inside the string), while psql, run through the actual rendered command line, closes the string at that point and treats the following ) as the end of the wrapping \copy (...) subquery, exposing an attacker-chosen TO PROGRAM &#39;&lt;command&gt;&#39; clause that psql executes via popen() -- independent of a subsequent syntax error later on the same line. This is the same class of bug as CVE-2025-12762/CVE-2025-13780 (RCE via…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-17566 https://cve.radiocsirt.org/vuln/ghsa-3h25-h4m7-gr36 <p>pgAdmin 4&#39;s Import/Export Data tool builds a psql \copy (...) command line by interpolating a user-supplied SQL query into a Jinja template and passing the rendered line to psql via --command. To stop an attacker from breaking out of the (...) wrapper, create_import_export_job() (route POST /import_export/job/&lt;sid&gt;, gated only by the ordinary, commonly-granted tools_import_export_data permission) validated the query with a hand-written parenthesis-balance checker, _is_query_parens_balanced(). That checker always treated a backslash before a single quote (\&#39;) as escaping the quote, i.e. as if standard_conforming_strings were off. PostgreSQL has defaulted standard_conforming_strings to on since 9.1 (2010), the default on every PostgreSQL version pgAdmin 4 currently supports (13-18); under that default psql&#39;s own \copy tokenizer treats \ as an ordinary character, so a single quote immediately after it closes the string literal. A query such as SELECT &#39;a\&#39;) TO PROGRAM &#39;echo pwned&#39; x&#39; was therefore accepted as &#34;balanced&#34; by pgAdmin&#39;s checker (which believed the ) was still inside the string), while psql, run through the actual rendered command line, closes the string at that point and treats the following ) as the end of the wrapping \copy (...) subquery, exposing an attacker-chosen TO PROGRAM &#39;&lt;command&gt;&#39; clause that psql executes via popen() -- independent of a subsequent syntax error later on the same line. This is the same class of bug as CVE-2025-12762/CVE-2025-13780 (RCE via…</p> <p>pgAdmin 4&#39;s Import/Export Data tool builds a psql \copy (...) command line by interpolating a user-supplied SQL query into a Jinja template and passing the rendered line to psql via --command. To stop an attacker from breaking out of the (...) wrapper, create_import_export_job() (route POST /import_export/job/&lt;sid&gt;, gated only by the ordinary, commonly-granted tools_import_export_data permission) validated the query with a hand-written parenthesis-balance checker, _is_query_parens_balanced(). That checker always treated a backslash before a single quote (\&#39;) as escaping the quote, i.e. as if standard_conforming_strings were off. PostgreSQL has defaulted standard_conforming_strings to on since 9.1 (2010), the default on every PostgreSQL version pgAdmin 4 currently supports (13-18); under that default psql&#39;s own \copy tokenizer treats \ as an ordinary character, so a single quote immediately after it closes the string literal. A query such as SELECT &#39;a\&#39;) TO PROGRAM &#39;echo pwned&#39; x&#39; was therefore accepted as &#34;balanced&#34; by pgAdmin&#39;s checker (which believed the ) was still inside the string), while psql, run through the actual rendered command line, closes the string at that point and treats the following ) as the end of the wrapping \copy (...) subquery, exposing an attacker-chosen TO PROGRAM &#39;&lt;command&gt;&#39; clause that psql executes via popen() -- independent of a subsequent syntax error later on the same line. This is the same class of bug as CVE-2025-12762/CVE-2025-13780 (RCE via…</p> https://cve.radiocsirt.org/vuln/ghsa-3h25-h4m7-gr36 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