CVE-2026-116251 in pgAdmin
Summary
by MITRE • 10/30/2026
pgAdmin 4 did not invalidate a user's existing sessions when their password changed, either through the user's own change password dialog or through an administrator resetting it in User Management. A session established before the change, for example on another device or by someone who had obtained the old password or a session cookie, therefore stayed logged in after the change, which is the step a user or administrator takes precisely to cut such access off. It remained usable until it expired.
The fix rotates the user's session identifier (fs_uniquifier) whenever the password is changed, so every other session of that user is logged out. The session that made the change is logged in again and keeps its database connections. Saved server passwords, including those for shared servers, are re-encrypted under the new key; any that cannot be decrypted are cleared and the user is told. If re-encryption fails, the sessions are still revoked and the saved passwords are cleared rather than the change failing.
This issue affects pgAdmin 4: before 9.19.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability in pgAdmin 4 prior to version 9.19 represents a critical failure in session management logic, specifically regarding the invalidation of active sessions upon credential modification. This flaw allows an attacker who has obtained valid credentials or captured a session cookie from before a password change to maintain persistent access to the application and its associated database connections indefinitely until the existing session token naturally expires. The core technical issue stems from the application's failure to rotate the user-specific session identifier, known as fs_uniquifier, when a password is updated. In secure authentication architectures, changing credentials should serve as an immediate revocation mechanism for all prior sessions, ensuring that any unauthorized access attempts using old tokens are rejected by the server. Instead, pgAdmin 4 treated the password change as an isolated credential update without affecting the state of existing authenticated contexts. This design oversight means that a session established on another device or hijacked through cookie theft remains fully functional and privileged after the legitimate user changes their password to mitigate the breach.
From a security standards perspective, this vulnerability aligns with CWE-613, which describes insufficient session expiration, but more critically it maps to CWE-287, Improper Authentication, due to the failure to verify current credentials against updated secrets during subsequent requests within an existing session context. Furthermore, in the MITRE ATT&CK framework, this behavior facilitates Persistence and Defense Evasion techniques, as attackers can leverage long-lived sessions to maintain footholds even after defensive measures like password resets are enacted by administrators or victims. The operational impact is severe because it undermines a primary incident response action: resetting passwords to cut off unauthorized access. An adversary who has compromised an account does not need to wait for session timeouts; they retain full administrative capabilities within the pgAdmin interface, potentially allowing them to exfiltrate data, modify database schemas, or execute arbitrary commands on connected PostgreSQL servers without detection until the token expires naturally.
The remediation implemented in version 9.19 addresses this by enforcing a strict rotation of the fs_uniquifier whenever password changes occur through either the user-facing dialog or administrative reset functions. This cryptographic rotation ensures that all existing session tokens become invalid immediately, forcing re-authentication with the new credentials and effectively logging out any unauthorized parties who may have retained access via old cookies. The fix also handles edge cases related to saved server passwords by attempting to re-encrypt them under a new key derived from the updated password. If decryption fails due to corruption or mismatched keys, the system clears these sensitive stored values rather than allowing the session revocation process to fail silently. This approach prioritizes security continuity over data retention of cached credentials, ensuring that even if saved passwords are lost during the transition, the primary goal of terminating unauthorized sessions is achieved without compromising the integrity of the authentication flow.
To mitigate this risk in environments running affected versions, immediate upgrade to pgAdmin 4 version 9.19 or later is required. For organizations unable to patch immediately, implementing network-level controls such as short-lived session timeouts and strict cookie attributes like HttpOnly and Secure can reduce the window of opportunity for attackers exploiting stale sessions. Additionally, monitoring for unusual login patterns from multiple geographic locations or devices shortly after a password change event may help detect exploitation attempts where an attacker retains access via an old session token while the legitimate user believes they have secured their account. Regular audits of active sessions and enforcement of automatic logout policies on credential changes are essential best practices to prevent similar vulnerabilities in other web applications that manage sensitive database administration tasks.