pgAdmin 4 EUVD-2026-114380

Requires valid credentials for an LDAP directory or Kerberos realm that pgAdmin is configured to use (PR:L), and applies ONLY to pgAdmin 4 server mode before 9.19 - desktop mode is explicitly unaffected. A username collision must exist across authentication sources: the directory username must match another account's username, e.g. an LDAP/Kerberos user whose username equals an internal account (including the default administrator). The second variant additionally requires internal authentication to be listed before LDAP or Kerberos in AUTHENTICATION_SOURCES, which causes Flask-Security's internal form validation to look up the typed email's account and retain it even though the password did not match, letting a directory user log in as another user of the same source. Limiting factors: no anonymous access (a working directory login is mandatory), the flaw is absent in desktop mode and in versions 9.19+, and the second variant depends on non-default source ordering.

This is a genuine authentication/authorization flaw (CWE-287) in pgAdmin 4 server mode, well-substantiated by vendor source evidence (two fix commits plus issue #10675), not a speculative high-CVSS inflation. The supplied CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N, score 8.9) is internally consistent with the description: network-reachable web login (AV:N), requiring an already-valid low-privilege directory credential (PR:L), with success gated on preconditions outside the attacker's sole control - a cross-source username collision and, for one variant, a specific AUTHENTICATION_SOURCES ordering (AC:H/AT:P). The impact metrics (VC:H/VI:H/VA:H, SC:H/SI:H) are credible because a successful bind yields another account's role, servers and saved database passwords - including the default administrator - which extends compromise to the downstream PostgreSQL systems. The vuln.today decision label is 'this_week', consistent with a serious but condition-dependent privilege flaw rather than an emergency. No CISA KEV listing, no EPSS score, and no proof-of-concept are present in the input; the only references are patch commits and the tracking issue. The absence of KEV/EPSS/PoC is not evidence of safety but does mean exploitation is, per available data, not confirmed in the wild - treat as targeted-capable given it needs valid LDAP/Kerberos credentials and a known colliding username.

In a pgAdmin 4 server-mode deployment using LDAP or Kerberos, an attacker who holds a valid directory credential authenticates with a username that matches an internal account - for example the default administrator created at setup. Because pgAdmin selected the login account by username alone (or trusted the account Flask-Security's internal form had looked up) without verifying the authenticating source, the attacker's session is bound to that other account, inheriting its role, configured servers and saved database passwords. No public exploit identified at time of analysis; the only references are the fix commits and tracking issue.