Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

Skip to content
Check your stack
CVE-2026-116238critical9.2

pgAdmin 4: The failed login limit can be bypassed, and Flask-Security's own views skip pgAdmin's login and password checks

Impact

In server mode pgAdmin 4 locks an internal account after MAX_LOGIN_ATTEMPTS failed logins (3 by default). The limit could be bypassed, giving an unauthenticated attacker an unlimited number of password guesses against any internal account, including the administrator's, in the default configuration:

Source excerpt · PostgreSQL

Affected packages

This source has no supported package-version data for matching. You can read the advisory here, but this record alone cannot power a dependency check.

Affected products

Vendor version evidence. Product records are separate from automatic dependency matching.

pgadmin.org · PostgreSQL

pgAdmin 4

1 range

Compare with this publisher’s ranges. This does not inspect your installation.

affected

0 → before 9.19

custom versions

unaffected

unknown

Other versions: unaffected

Original source description

In server mode pgAdmin 4 locks an internal account after MAX_LOGIN_ATTEMPTS failed logins (3 by default). The limit could be bypassed, giving an unauthenticated attacker an unlimited number of password guesses against any internal account, including the administrator's, in the default configuration:

  • Flask-Security registers its own views next to pgAdmin's. A login submitted to its /login view was checked and logged in without pgAdmin's failed login count or lock. Its /verify view checked a signed-in user's password without limit, its /change view changed a password without pgAdmin's change password permission or re-encrypting the user's saved server passwords, and its /reset views sent and applied password resets for accounts that are not internal or are locked.
  • The internal account was looked up by its exact username, while the login form matches the email ignoring case, so a login with the username typed in another case was neither counted nor checked for the lock.
  • With LDAP or webserver authentication also configured, a wrong internal password was never counted, and with Kerberos or webserver authentication configured a guess could be answered without being counted.

In addition, where accounts from different authentication sources share an email address, a password reset could be sent for, or applied to, an account from another source, and the About box showed the server configuration to a user whose email was that of an administrator's account.

The fix refuses submissions to Flask-Security's own views, counts every failed internal login however the username is typed and whatever other sources are configured, no longer lets a login that posts a password fall back to an authentication source that does not check it, and locks only internal authentication. Password resets and the About box act only on the user's own internal account. Desktop mode is not affected.

This issue affects pgAdmin 4: before 9.19.

Inside the record

Evidence available

Package identity · not supplied
Version evidence
Remediation guidance · not supplied
Weakness classification
Additional publishers · not supplied

Describes the evidence in this view, not whether the product is safe.

Original records

CVE-2026-116238

View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.

cve.new JSON →

Underlying weaknesses

The source’s classification of what caused the vulnerability.

CWE-307 ↗

CWE-307 Improper Restriction of Excessive Authentication Attempts

PostgreSQL

Related →
CWE-863 ↗

CWE-863 Incorrect Authorization

PostgreSQL

Related →
Contributing organizations · 1
PostgreSQL

Assigning organization

2026-10-30

What changed

Follow changes
No substantive changes have been recorded here yet. History starts when cve.new observes a change after tracking is enabled; earlier edits are not reconstructed.

Large field values are marked as truncated previews. Original source snapshots remain retained.

References

4 sources