CVE-2026-17349

Popis

/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-s (in practice, typically an administrator-s) shared server, the clone inherited that user-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-s stored database password on the non-owner-s behalf, granting the non-owner use of database credentials -- and whatever database privileges they confer -- that were never their own. Fix forces the cloned adhoc record-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-s ownership, sharing state, or stored credentials. A regression test asserts that an adhoc connect triggered by a non-owner against another user-s shared server persists a row owned by the caller, not shared, and without the source-s stored credentials. This issue affects pgAdmin 4: from 9.0 before 9.17.