pgAdmin 4 EUVD-2026-114379

pgAdmin 4 must run in server (web) mode using internal authentication with the default MAX_LOGIN_ATTEMPTS limit (3); desktop mode is explicitly not affected. Any one of several concrete prerequisites enables the bypass: reachability of Flask-Security's separately registered /login, /verify, /change or /reset views; supplying the target internal username in a different letter case than stored (the lock is looked up by exact username while the form matches email case-insensitively); or a deployment that also configures LDAP or webserver authentication (a wrong internal password is never counted) or Kerberos/webserver authentication (a guess can be answered without being counted). Related impacts require shared email addresses across auth sources (cross-source password reset) or a non-admin user whose email matches an administrator's (About-box server-config disclosure). The principal limiting factor is that the flaw only removes rate limiting - it does not reveal credentials, so compromise still depends on successfully brute-forcing a guessable password against an existing internal account.

This is a genuine high-priority issue, not a high-score-but-low-risk artifact. The input CVSS 4.0 vector is AV:N/AC:H/AT:P/PR:N/UI:N with VC:H/VI:H/VA:H (score 9.2), and the vuln.today decision label is act_now, so the urgency signals and the network/unauthenticated reach (AV:N, PR:N, UI:N) agree that this warrants prompt remediation. The practical mechanism is low-effort - the patch shows multiple independent ways to bypass the lockout (posting directly to Flask-Security's own /login, /verify, /change and /reset views; typing the internal username in a different letter case so the lock lookup misses; or relying on a coexisting LDAP/webserver/Kerberos source so a wrong internal password is never counted) - so the AC:H/AT:P metrics do NOT reflect a hard-to-reach bug; they instead reflect that the flaw removes the brute-force rate limit rather than directly yielding credentials. Success still depends on guessing the password, which is the attack requirement (AT:P) and the main real-world limiter. No CISA KEV listing is present in the input (so this is not confirmed actively exploited), and no EPSS probability was supplied, so widespread-exploitation likelihood cannot be quantified from the data given. The confirmed worst case is full takeover of a server-mode pgAdmin administrator account, which exposes the saved connection credentials for managed PostgreSQL servers - hence the uniformly High impact rating is credible.

An attacker who can reach a server-mode pgAdmin 4 web login submits unlimited password guesses against the administrator's internal account - for example by posting to Flask-Security's own /login view, or by sending the admin username in a different letter case - neither of which increments pgAdmin's failed-login counter or trips the default 3-attempt lock. Once a guess succeeds, the attacker logs in as administrator and gains access to the configured database-server connections and their saved passwords. No public exploit identified at time of analysis; the only referenced artifacts are the fix commits and tracking issue.