pgAdmin 4 EUVD-2026-114388

Requires pgAdmin 4 running in server (multi-user web) mode - desktop mode is explicitly unaffected. The attacker must be an already-authenticated pgAdmin user (PR:L) and must target a server definition for which no password file, client certificate, or client key is configured, or whose configured path cannot be found. The exploitation only succeeds if the OS account running pgAdmin actually holds the libpq default credential files (~/.pgpass, ~/.postgresql/postgresql.crt and postgresql.key) or the PGPASSFILE/PGSSLCERT/PGSSLKEY environment variables, and for the utility path a pg_service.conf entry or a maintenance-database-name-as-connection-string consumed by pg_dumpall can reintroduce the same files. For the certificate case, the attacker needs only a copy of the service account's public certificate, since libpq pairs it with the private key. Limiting factors: server mode only, prior authenticated access, the non-default presence of service-account credential files, and versions before 9.19.

This is a genuine but conditional credential-exposure issue (CWE-522), not a drive-by remote code execution. The input provides no EPSS score, no CISA KEV listing, and no proof-of-concept - the only references are the fix commit and the tracking issue on GitHub, so there is no public exploit identified at time of analysis. The vuln.today decision label is 'this_week', consistent with a medium-high but non-emergency priority. The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N) is self-consistent with the description: it is network-reachable but requires an already-authenticated low-privilege pgAdmin user (PR:L), carries a real attack requirement (AT:P) because the service account must actually have the default libpq credential files present in its home directory or environment, and is high-complexity (AC:H) because it depends on that non-default state plus a server defined without its own passfile/cert/key. The high confidentiality/integrity impact on the subsequent system (VC:H/SC:H/SI:H) reflects that a successful attacker connects to a PostgreSQL server as the pgAdmin service account. Net: a real priority for multi-tenant server-mode pgAdmin deployments where the OS account holds saved database credentials, but the preconditions (server mode, existing service-account credential files, a misconfigured/absent per-user credential) meaningfully narrow real-world exploitability. Desktop mode is explicitly unaffected.

In a shared server-mode pgAdmin 4 instance, a low-privileged authenticated user opens or registers a server whose password file and client certificate/key are not set (or point to a missing file). Because pgAdmin omitted those parameters, libpq silently falls back to the OS service account's ~/.pgpass or ~/.postgresql client certificate/key, letting that user authenticate to the target PostgreSQL server using the service account's stored secrets - and supplying only a copy of the public certificate is enough for libpq to pair it with the service account's private key. No public exploit code is identified; the only published artifacts are the vendor fix commit and issue.