pgAdmin 4 up to 9.14 /authenticate/login User.locked excessive authentication

Summaryinfo

A vulnerability marked as problematic has been reported in pgAdmin 4 up to 9.14. Affected is an unknown function of the file /authenticate/login. Performing a manipulation of the argument User.locked results in excessive authentication. This vulnerability is known as CVE-2026-7820. Remote exploitation of the attack is possible. No exploit is available. It is suggested to upgrade the affected component.

Detailsinfo

A vulnerability was found in pgAdmin 4 up to 9.14. It has been classified as problematic. This affects an unknown code of the file /authenticate/login. The manipulation of the argument User.locked with an unknown input leads to a excessive authentication vulnerability. CWE is classifying the issue as CWE-307. The product does not implement sufficient measures to prevent multiple failed authentication attempts within a short time frame, making it more susceptible to brute force attacks. This is going to have an impact on confidentiality. The summary by CVE is:

Improper restriction of excessive authentication attempts (CWE-307) in pgAdmin 4. pgAdmin enforces MAX_LOGIN_ATTEMPTS only inside its custom /authenticate/login view. Flask-Security's default /login view, which is registered automatically by security.init_app() and is reachable on every server, never consulted the User.locked field: pgAdmin's User model relied on Flask-Security's UserMixin.is_locked() (which always returns 'not locked') and Flask-Login's is_active (which only checks the active column, not locked). An attacker who triggered an account lockout via /authenticate/login could therefore obtain a session by re-submitting valid credentials directly to /login, defeating the brute-force-protection control for accounts using the INTERNAL authentication source. The same bypass also means that login attempts via /login are never rate-limited, so an attacker can perform an unbounded online password-guessing attack against INTERNAL accounts regardless of MAX_LOGIN_ATTEMPTS. Fix overrides User.is_active and User.is_locked() so the locked column is enforced on every authentication path. LDAP, OAuth2, Kerberos, and Webserver users are not reachable by this bypass because they have no local password and are rejected by Flask-Security's LoginForm.validate before the locked check; the lockout itself is also internal-only (the /authenticate/login view filters by auth_source=INTERNAL). This issue affects pgAdmin 4: before 9.15.

The weakness was published by Fernando Bortotti. The advisory is shared at github.com. This vulnerability is uniquely identified as CVE-2026-7820 since 05/04/2026. The exploitability is told to be easy. It is possible to initiate the attack remotely. No form of authentication is needed for exploitation. Technical details are known, but no exploit is available. MITRE ATT&CK project uses the attack technique T1110.001 for this issue.

Upgrading to version 9.15 eliminates this vulnerability.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Name

• pgAdmin 4

Version

• 9.0
• 9.1
• 9.2
• 9.3
• 9.4
• 9.5
• 9.6
• 9.7
• 9.8
• 9.9
• 9.10
• 9.11
• 9.12
• 9.13
• 9.14

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion