pgAdmin 4 CVE-2026-116251

Exploitation requires that the attacker ALREADY possesses the victim's pre-change password or a valid pre-change pgAdmin session cookie, and that a password change or administrator reset then occurs for that user. The vulnerability only manifests in that window: the stale session remains usable from the change until its natural session expiry - it grants no new access on its own. Affected deployments are pgAdmin 4 before 9.19. Limiting factors: the attacker needs prior credential or cookie compromise (PR:L), the benefit depends on a password-change event happening (AT:P), and the exposure self-heals when the old session expires; the issue applies equally to a user's own change-password dialog and to admin resets in User Management, including shared-server saved passwords.

All available signals point to genuinely low priority. The supplied CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N) scores only 2.3, and the vuln.today decision label is 'monitor' - not act_now or emergency. There is no CISA KEV listing, no EPSS probability provided in the input, and no exploit code: the two references are the fix commit and the GitHub issue, i.e. patch/source artifacts, not a PoC. Exploitation status is therefore 'no public exploit identified at time of analysis'. The CWE-613 nature reinforces this: the flaw does not grant new access but allows an attacker who ALREADY holds the victim's old password or a valid session cookie to retain access past the exact moment (a password change or admin reset) that was meant to revoke it. The AT:P (attack requirement present) and AC:H reflect that the attacker must already possess prior credentials/cookie and that a password-change event must occur - this is a defense-in-depth session-hygiene gap, not a remotely weaponizable entry point. No signals conflict; low CVSS, 'monitor' label, absent KEV, and absent exploit code all agree this is a low-real-risk hardening fix rather than an active threat.

An attacker who previously captured a pgAdmin user's password or session cookie (e.g. on a shared or formerly-trusted device) keeps an authenticated session open. The legitimate user or an administrator, suspecting compromise, changes or resets the password specifically to lock the attacker out - but on versions before 9.19 the attacker's pre-existing session stays logged in and usable until it naturally expires. No public exploit code exists; the referenced links are the fix commit and issue, not a PoC.