pgAdmin 4 CVE-2026-116244

Requires a pgAdmin 4 server-mode (multi-user web) deployment and an authenticated pgAdmin user (PR:L). The OS account running pgAdmin must possess usable Kerberos credentials - a default credential cache, a client keytab, or (on Windows) an SSPI logon - and the target PostgreSQL server must offer/request GSSAPI or SSPI authentication; gssproxy environments are also affected. Exploitation lets any user connect as the service account's Kerberos principal regardless of the username entered. Limiting factors: the flaw does not apply to single-user desktop mode, and it is gated on the service account actually having Kerberos credentials present and a server requesting GSSAPI/SSPI (hence AC:H/AT:P). Important caveat for defenders: setting gssencmode=disable did NOT block the fallback, and the require_auth-based refusal in the fix only works with libpq 16 or later - older libpq retains only the KRB5CCNAME/KRB5_CLIENT_KTNAME isolation, which does not cover Windows SSPI or gssproxy. Complete remediation is upgrading to pgAdmin 4 9.19.

This is a credential-misuse/authentication-bypass flaw (CWE-522) in pgAdmin 4 server mode, scored 7.1 by the supplied CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N). The signals are internally consistent and point to a real but conditional priority rather than a drop-everything emergency. Attack vector is network and impact is high on the subsequent system (the PostgreSQL server: SC:H/SI:H), which is why it rates above 7, but PR:L means the attacker must already be an authenticated pgAdmin user, and AC:H/AT:P reflect that exploitation depends on conditions outside the attacker's control - the OS account running pgAdmin must actually hold usable Kerberos credentials (a default credential cache, client keytab, or Windows SSPI logon) and the target server must request GSSAPI/SSPI. The vendor priority label is 'this_week'. There is no CISA KEV entry and no EPSS probability was supplied, so widespread automated exploitation is not evidenced; the only references are the fix commit and the issue tracker, i.e. no public exploit identified at time of analysis. A notable detail that raises concern is that the pre-fix mitigation operators might expect - gssencmode=disable - did NOT prevent the fallback, so defenders cannot assume disabling GSSAPI encryption closed the hole. Net: a genuine privilege/identity escalation worth patching promptly in multi-user Kerberos deployments, but gated by server mode and the presence of service-account Kerberos credentials rather than a universal remote-unauthenticated risk.

In a multi-user pgAdmin server-mode deployment, a logged-in pgAdmin user defines a connection to a PostgreSQL server that requests GSSAPI (or SSPI on Windows) authentication, supplying any username. Because pgAdmin stripped KRB5CCNAME from the environment, libpq falls back to the default credential cache / client keytab (or Windows logon) of the OS account running pgAdmin and authenticates as that service account's Kerberos principal, granting the user database access as the service identity regardless of the name they entered. No public exploit identified at time of analysis; exploitation is conditional (AC:H/AT:P) on the service account's Kerberos credentials being present.