pgAdmin 4 EUVD-2026-114387

Requires pgAdmin 4 (before 9.19) running in server mode (multi-user web deployment), where pgAdmin's single process environment is shared across all users' requests. The attacker must be an authenticated pgAdmin user (PR:L) and must connect to a target server using a saved connection that has no password of its own, so libpq falls back to the inherited PGPASSWORD. Exploitation also depends on timing: another user must have previously triggered a psql session or background utility that wrote a password into the shared environment, and that value must still be present. These are the limiting factors - single-user desktop installations are not affected, the condition is opportunistic rather than attacker-controlled (reflected in AC:H and AT:P), and the attacker gains only whatever database access the victim's credentials allow. The complete fix is upgrading to pgAdmin 4 9.19; the vendor provides no separate mitigation.

This is a genuine but conditional multi-user privacy flaw rather than a mass-exploitation emergency. The input CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:P, score 7.0) tells a consistent story: network-reachable but with high attack complexity (AC:H) and a specific attack requirement (AT:P), low-privilege authentication required (PR:L), and some passive user interaction (UI:P). Those modifiers align with the described mechanism - an attacker must already be an authenticated pgAdmin user in server mode and must rely on another user having earlier run psql or a background utility that left its password (PGPASSWORD or a per-process variable) in pgAdmin's shared process environment; the attacker then makes a connection with no password of its own so libpq falls back to the inherited value. No EPSS score is provided in the input, so exploitation probability cannot be quantified. KEV status is not listed (treat as not present), and the only references are the fix commit and the GitHub issue, so there is no public exploit identified at time of analysis - though the fix commit publicly discloses the exact mechanism. The vuln.today decision label is 'this_week', which, combined with high confidentiality impact (VC:H) and a subsequent-system confidentiality impact (SC:H, i.e. access to a database the victim could reach), warrants prompt patching but does not indicate act_now/emergency-level active exploitation. Net: a real priority for anyone running pgAdmin in multi-user server mode, materially lower risk for single-user desktop deployments.

In a shared pgAdmin server-mode deployment, a low-privileged but authenticated user waits until another user runs a psql session or a background utility (backup, restore, import) that writes that user's database password into pgAdmin's shared process environment. Because nothing clears it and every new process inherits the environment, the attacker then opens their own connection to the same server without supplying a password, and libpq silently reuses the victim's leaked PGPASSWORD, logging the attacker in with another user's saved credentials. No public exploit code is identified at time of analysis, and the high attack complexity plus required timing of a victim's process limit reliability.