CVE-2026-116238

What it is

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.

At a glance

Exploitability

Can be exploited over the network without logging in. High risk of data exposure, data tampering, service disruption.

Exploit odds

0.4% chance of exploitation in the next 30 days (EPSS).

Fix

A patch, advisory or fixed version is referenced. Upgrade or apply it.

Timeline

1. 2026-10-25 16:26 UTC ReservedThe CVE id was reserved by its CNA
2. 2026-10-30 20:17 UTC PublishedDisclosed publicly on CVE.org and NVD
3. 2026-11-09 15:45 UTC Last updatedMost recent change to the record

Why it ranks here

• Exploited in the wild: no, CISA does not list it.
• Exploit odds: 0.4% in the next 30 days (EPSS).
• Severity: 9.2 CRITICAL (CVSS).
• Fix: a patch or advisory is linked.

Details

Published

2026-10-30 20:17 UTC

Last modified

2026-11-09 15:45 UTC

Exploit probability

0.4% · EPSS, next 30 days

Weakness

CWE-307

Record status

Analyzed

Affected

• Pgadmin 4 < 9.19

Attack profile CVSS 4.0 · 9.2

Attack vector

Network

Complexity

High

Attack requirements

Present

Privileges needed

None

User interaction

None

Confidentiality

High

Integrity

High

Availability

High

Is it in your code?

Hand this to your coding agent. It searches your project for the affected products and checks versions. Nothing leaves your machine.

Read https://cve-list.com/agent/cve/CVE-2026-116238.md and follow it. Check whether this project is affected by CVE-2026-116238. Read only. Don't change anything and don't upload my code. Tell me yes, no or not sure, with the file as proof.

Copy as ticket · More options · Status badge