https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 08:51:06 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-15252 bdu:2026-15252 https://cve.radiocsirt.org/vuln/bdu:2026-15252 https://cve.radiocsirt.org/vuln/euvd-2026-329098 EUVD-2026-329098 https://cve.radiocsirt.org/vuln/euvd-2026-329098 https://cve.radiocsirt.org/vuln/fkie_cve-2026-12044 <p>SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ... IS &#39;&lt;description&gt;&#39;`` for a user-supplied description field. The Jinja templates for Domains (and their constraints), Foreign Tables, Languages, and Event Triggers, plus the Views OID-lookup query, interpolated the description directly inside a single-quoted SQL literal -- ``&#39;{{ data.description }}&#39;`` -- instead of passing it through the ``qtLiteral`` escape filter. An authenticated pgAdmin user with permission to create or alter the affected object types could submit a description containing an apostrophe, break out of the literal and chain arbitrary SQL. The injected SQL runs under the PostgreSQL role the user is already authenticated as; for a connected role with ``COPY ... TO/FROM PROGRAM`` (typically PostgreSQL superuser), this chains to OS command execution on the PostgreSQL host. The defect does not cross a privilege boundary -- the user already has direct SQL access to that role through pgAdmin&#39;s Query Tool -- so the attacker gains no capability beyond what their database role already grants. The marginal impact captures bypass of any application-layer Query Tool gating an operator may have configured.</p> <p>The defect was originally reported against the Domain Dialog ``description`` field; a code-wide audit identified sixteen sites of the same pattern across the templates listed above. The same review also surfaced ten related sinks in the pgstattuple/pgstatindex stats templates -- ``pgs…</p> <p>SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ... IS &#39;&lt;description&gt;&#39;`` for a user-supplied description field. The Jinja templates for Domains (and their constraints), Foreign Tables, Languages, and Event Triggers, plus the Views OID-lookup query, interpolated the description directly inside a single-quoted SQL literal -- ``&#39;{{ data.description }}&#39;`` -- instead of passing it through the ``qtLiteral`` escape filter. An authenticated pgAdmin user with permission to create or alter the affected object types could submit a description containing an apostrophe, break out of the literal and chain arbitrary SQL. The injected SQL runs under the PostgreSQL role the user is already authenticated as; for a connected role with ``COPY ... TO/FROM PROGRAM`` (typically PostgreSQL superuser), this chains to OS command execution on the PostgreSQL host. The defect does not cross a privilege boundary -- the user already has direct SQL access to that role through pgAdmin&#39;s Query Tool -- so the attacker gains no capability beyond what their database role already grants. The marginal impact captures bypass of any application-layer Query Tool gating an operator may have configured.</p> <p>The defect was originally reported against the Domain Dialog ``description`` field; a code-wide audit identified sixteen sites of the same pattern across the templates listed above. The same review also surfaced ten related sinks in the pgstattuple/pgstatindex stats templates -- ``pgs…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-12044 https://cve.radiocsirt.org/vuln/ghsa-hrvw-6gvm-9x99 <p>SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ... IS &#39;&lt;description&gt;&#39;`` for a user-supplied description field. The Jinja templates for Domains (and their constraints), Foreign Tables, Languages, and Event Triggers, plus the Views OID-lookup query, interpolated the description directly inside a single-quoted SQL literal -- ``&#39;{{ data.description }}&#39;`` -- instead of passing it through the ``qtLiteral`` escape filter. An authenticated pgAdmin user with permission to create or alter the affected object types could submit a description containing an apostrophe, break out of the literal and chain arbitrary SQL. The injected SQL runs under the PostgreSQL role the user is already authenticated as; for a connected role with ``COPY ... TO/FROM PROGRAM`` (typically PostgreSQL superuser), this chains to OS command execution on the PostgreSQL host. The defect does not cross a privilege boundary -- the user already has direct SQL access to that role through pgAdmin&#39;s Query Tool -- so the attacker gains no capability beyond what their database role already grants. The marginal impact captures bypass of any application-layer Query Tool gating an operator may have configured.</p> <p>The defect was originally reported against the Domain Dialog ``description`` field; a code-wide audit identified sixteen sites of the same pattern across the templates listed above. The same review also surfaced ten related sinks in the pgstattuple/pgstatindex stats templates -- ``pgs…</p> <p>SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ... IS &#39;&lt;description&gt;&#39;`` for a user-supplied description field. The Jinja templates for Domains (and their constraints), Foreign Tables, Languages, and Event Triggers, plus the Views OID-lookup query, interpolated the description directly inside a single-quoted SQL literal -- ``&#39;{{ data.description }}&#39;`` -- instead of passing it through the ``qtLiteral`` escape filter. An authenticated pgAdmin user with permission to create or alter the affected object types could submit a description containing an apostrophe, break out of the literal and chain arbitrary SQL. The injected SQL runs under the PostgreSQL role the user is already authenticated as; for a connected role with ``COPY ... TO/FROM PROGRAM`` (typically PostgreSQL superuser), this chains to OS command execution on the PostgreSQL host. The defect does not cross a privilege boundary -- the user already has direct SQL access to that role through pgAdmin&#39;s Query Tool -- so the attacker gains no capability beyond what their database role already grants. The marginal impact captures bypass of any application-layer Query Tool gating an operator may have configured.</p> <p>The defect was originally reported against the Domain Dialog ``description`` field; a code-wide audit identified sixteen sites of the same pattern across the templates listed above. The same review also surfaced ten related sinks in the pgstattuple/pgstatindex stats templates -- ``pgs…</p> https://cve.radiocsirt.org/vuln/ghsa-hrvw-6gvm-9x99 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-2005 <p>Ein entfernter, authentisierter Angreifer kann mehrere Schwachstellen in pgAdmin ausnutzen, um beliebigen Code mit Benutzer- oder Administratorrechten auszuführen, Sicherheitsmaßnahmen zu umgehen, SQL-Injection- und Cross-Site-Scripting-Angriffe durchzuführen, Benutzer auf bösartige Websites umzuleiten, vertrauliche Informationen offenzulegen oder Daten zu manipulieren.</p> <p>Ein entfernter, authentisierter Angreifer kann mehrere Schwachstellen in pgAdmin ausnutzen, um beliebigen Code mit Benutzer- oder Administratorrechten auszuführen, Sicherheitsmaßnahmen zu umgehen, SQL-Injection- und Cross-Site-Scripting-Angriffe durchzuführen, Benutzer auf bösartige Websites umzuleiten, vertrauliche Informationen offenzulegen oder Daten zu manipulieren.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2005