pgAdmin 4 EUVD-2026-114383

Requires a pgAdmin 4 deployment running in server (web) mode specifically - the flaw does not apply to desktop/runtime mode, where the account pgAdmin runs as is the user. An attacker must have a valid low-privileged pgAdmin user account (PR:L) and the ability to define a server connection using an SSH tunnel. Exploitation further depends on environment conditions outside the attacker's control (hence AC:H/AT:P): the OS account running pgAdmin must possess unencrypted private keys in ~/.ssh, a ~/.ssh/config entry (IdentityFile, User, HostName, ProxyCommand), or a reachable ssh-agent, AND the targeted SSH host must accept that service account's key. The attacker can succeed with no identity file of their own or with an identity file that does not exist in their storage. What limits exploitation: requires authentication to pgAdmin, requires the server-mode (non-runtime) deployment, and yields nothing unless some reachable host actually trusts the service account's credentials.

This is a genuine authorization/credential-exposure flaw (CWE-522) in pgAdmin 4 server mode, but its real-world risk is moderate rather than critical, consistent with the 7.1 CVSS 4.0 score and the 'this_week' priority label. The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N) tells us it is network-reachable but requires an authenticated low-privileged pgAdmin account (PR:L) and carries both high attack complexity (AC:H) and a present attack requirement (AT:P) - the supplied evidence grounds AT:P/AC:H in the fact that exploitation depends on conditions the attacker does not fully control: the OS service account must actually hold usable keys in ~/.ssh, a populated ~/.ssh/config, or a live ssh-agent, AND a reachable SSH host must trust that account's key. The impact is serious where those conditions hold: VC:H plus subsequent-system SC:H/SI:H reflect that a user reaches a separate host as the shared service account with no credentials of their own. No EPSS score, no KEV listing, and no public exploit were provided, so there is no signal of active or widespread exploitation - this reads as a privilege/trust-boundary bug to be patched promptly rather than an emergency. Note one limit on the signals: the exploitation preconditions (service-account keys exist, target trusts them) are environment-specific and are not themselves captured by the CVSS vector, so raw severity may overstate risk in hardened deployments and understate it where the service account is heavily trusted.

In a pgAdmin server-mode deployment, a low-privileged authenticated user creates a server connection with an SSH tunnel pointed at a bastion or database host that trusts the SSH key of the OS account pgAdmin runs as, supplying no valid identity file of their own (or one that does not exist in their storage). Because pgAdmin passed sshtunnel neither host_pkey_directories nor ssh_config_file, the tunnel silently falls back to the service account's ~/.ssh keys, ~/.ssh/config and ssh-agent and authenticates as that shared account, letting the user reach a host for which they hold no credentials. No public exploit code was identified at time of analysis; the fix commit and issue describe the mechanism in detail.