Description
/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.
Published: 2026-07-31
Score: 9.3 Critical
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability allows a user who does not own a shared server to clone that server via pgAdmin 4’s ad hoc connect feature. The clone inherits the original owner’s database credentials, stored as plain text, and the original ownership and sharing flags. This means the non-owner not only receives a copy of the server configuration but also the actual password needed to connect to the database, effectively granting them the same database privileges as the original owner. The weakness resides in improper handling of stored credential data and authorization controls, matching CWE‑522 and CWE‑639.

Affected Systems

pgAdmin 4, versions beginning with 9.0 up through, but not including, 9.17. Users running these releases on any supported operating system are susceptible if they use the ad hoc connect feature on a shared server that belongs to a different user.

Risk and Exploitability

The CVSS score of 9.3 highlights the high severity of this flaw. The EPSS score of less than 1% indicates that exploitation is currently unlikely in the wild, and the vulnerability is not listed in the CISA KEV catalog. Attackers must be authenticated in pgAdmin 4 and have access to a shared server owned by another user; the exploit therefore follows an authenticated, insider or co‑tenant vector. Because the flaw persists even if the connection fails, an attacker can gain credentials without triggering external network activity. The combination of a high severity score, the potential to compromise database accounts, and the lack of mitigations in older versions suggests a substantial risk for organizations that rely on shared pgAdmin 4 workspaces.

Generated by OpenCVE AI on August 2, 2026 at 04:08 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Upgrade pgAdmin 4 to version 9.17 or later, which enforces correct ownership and clears stored credentials during ad hoc clone creation.
  • Identify and delete any existing ad hoc server records that may contain leaked credentials, especially records owned by users who should not have access.
  • Review user permissions in pgAdmin 4 to enforce least privilege, limiting the ability to access or clone shared servers that belong to other users.

Generated by OpenCVE AI on August 2, 2026 at 04:08 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Sat, 15 Aug 2026 12:15:00 +0000

Type Values Removed Values Added
References
Metrics threat_severity

None

threat_severity

Critical


Sun, 02 Aug 2026 19:30:00 +0000

Type Values Removed Values Added
First Time appeared Pgadmin
Pgadmin pgadmin 4
Vendors & Products Pgadmin
Pgadmin pgadmin 4

Fri, 31 Jul 2026 18:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'total'}, 'version': '2.0.3'}


Fri, 31 Jul 2026 16:15:00 +0000

Type Values Removed Values Added
Description /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.
Title pgAdmin 4: Adhoc server clone leaks another user's stored database credentials and ownership to a non-owner
Weaknesses CWE-522
CWE-639
References
Metrics cvssV3_1

{'score': 9.6, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N'}

cvssV4_0

{'score': 9.3, 'vector': 'CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:H/SI:H/SA:N'}


Subscriptions

Pgadmin Pgadmin 4
cve-icon MITRE

Status: PUBLISHED

Assigner: PostgreSQL

Published:

Updated: 2026-08-01T03:56:26.176Z

Reserved: 2026-07-25T02:52:56.082Z

Link: CVE-2026-17349

cve-icon Vulnrichment

Updated: 2026-07-31T17:21:46.538Z

cve-icon NVD

Status : Analyzed

Published: 2026-07-31T16:16:59.480

Modified: 2026-08-05T20:17:21.527

Link: CVE-2026-17349

cve-icon Redhat

Severity : Critical

Publid Date: 2026-07-31T15:59:47Z

Links: CVE-2026-17349 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-02T19:15:17Z

Weaknesses
  • CWE-522

    Insufficiently Protected Credentials

  • CWE-639

    Authorization Bypass Through User-Controlled Key