https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 15:15:09 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-343576 EUVD-2026-343576 https://cve.radiocsirt.org/vuln/euvd-2026-343576 https://cve.radiocsirt.org/vuln/fkie_cve-2026-17349 <p>/misc/workspace/adhoc_connect_server, part of the Workspaces feature introduced in pgAdmin 4 9.0, when passed the id of an existing server, clones that server via Server.clone(), which copies every column from the source row, including user_id, shared, shared_username, and the stored credential fields password, save_password, and tunnel_password. When a non-owner triggered an adhoc connect against another user&#39;s (in practice, typically an administrator&#39;s) shared server, the clone inherited that user&#39;s ownership, shared flag, and stored database credentials verbatim. pgAdmin persisted this cross-tenant, credential-bearing server row before the connection was even attempted, so it survived even when the connection subsequently failed. The non-owner could then open the newly-owned clone and pgAdmin would connect using the source user&#39;s stored database password on the non-owner&#39;s behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own.</p> <p>Fix forces the cloned adhoc record&#39;s ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server&#39;s ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user&#39;s shared server persists a row owned by the caller, not shared…</p> <p>/misc/workspace/adhoc_connect_server, part of the Workspaces feature introduced in pgAdmin 4 9.0, when passed the id of an existing server, clones that server via Server.clone(), which copies every column from the source row, including user_id, shared, shared_username, and the stored credential fields password, save_password, and tunnel_password. When a non-owner triggered an adhoc connect against another user&#39;s (in practice, typically an administrator&#39;s) shared server, the clone inherited that user&#39;s ownership, shared flag, and stored database credentials verbatim. pgAdmin persisted this cross-tenant, credential-bearing server row before the connection was even attempted, so it survived even when the connection subsequently failed. The non-owner could then open the newly-owned clone and pgAdmin would connect using the source user&#39;s stored database password on the non-owner&#39;s behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own.</p> <p>Fix forces the cloned adhoc record&#39;s ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server&#39;s ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user&#39;s shared server persists a row owned by the caller, not shared…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-17349 https://cve.radiocsirt.org/vuln/ghsa-p547-rjmg-jqr4 <p>/misc/workspace/adhoc_connect_server, part of the Workspaces feature introduced in pgAdmin 4 9.0, when passed the id of an existing server, clones that server via Server.clone(), which copies every column from the source row, including user_id, shared, shared_username, and the stored credential fields password, save_password, and tunnel_password. When a non-owner triggered an adhoc connect against another user&#39;s (in practice, typically an administrator&#39;s) shared server, the clone inherited that user&#39;s ownership, shared flag, and stored database credentials verbatim. pgAdmin persisted this cross-tenant, credential-bearing server row before the connection was even attempted, so it survived even when the connection subsequently failed. The non-owner could then open the newly-owned clone and pgAdmin would connect using the source user&#39;s stored database password on the non-owner&#39;s behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own.</p> <p>Fix forces the cloned adhoc record&#39;s ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server&#39;s ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user&#39;s shared server persists a row owned by the caller, not shared…</p> <p>/misc/workspace/adhoc_connect_server, part of the Workspaces feature introduced in pgAdmin 4 9.0, when passed the id of an existing server, clones that server via Server.clone(), which copies every column from the source row, including user_id, shared, shared_username, and the stored credential fields password, save_password, and tunnel_password. When a non-owner triggered an adhoc connect against another user&#39;s (in practice, typically an administrator&#39;s) shared server, the clone inherited that user&#39;s ownership, shared flag, and stored database credentials verbatim. pgAdmin persisted this cross-tenant, credential-bearing server row before the connection was even attempted, so it survived even when the connection subsequently failed. The non-owner could then open the newly-owned clone and pgAdmin would connect using the source user&#39;s stored database password on the non-owner&#39;s behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own.</p> <p>Fix forces the cloned adhoc record&#39;s ownership fields (user_id, shared, shared_username) and stored credential fields (password, save_password, tunnel_password) to belong to the calling user and be cleared/private before committing, regardless of the source server&#39;s ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user&#39;s shared server persists a row owned by the caller, not shared…</p> https://cve.radiocsirt.org/vuln/ghsa-p547-rjmg-jqr4 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