CVE-2026-116244 in pgAdmin
Summary
by MITRE • 10/30/2026
When a pgAdmin 4 connection was not meant to use a Kerberos user's delegated credentials, pgAdmin removed KRB5CCNAME from its environment, so the Kerberos library fell back to the default credential cache, or a client keytab, of the operating-system account running pgAdmin. libpq then answered any server that asked for GSSAPI authentication with that account's ticket, whatever user name the pgAdmin user gave, so in server mode any user could connect as the service account's Kerberos principal; gssencmode=disable did not prevent it. On Windows, SSPI used the service account's logon in the same way. psql was also started with pgAdmin's environment, which could hold another user's credential cache while that user was connecting.
The fix points KRB5CCNAME and KRB5_CLIENT_KTNAME at a file that cannot exist except while a Kerberos-authenticated user connects with Kerberos, and gives every other connection, psql and the utilities require_auth=!gss,!sspi and gssencmode=disable, checked on the final connection string. require_auth needs libpq 16 or later.
This issue affects pgAdmin 4: before 9.19.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability in pgAdmin 4 prior to version 9.19 represents a critical authentication bypass flaw rooted in improper handling of Kerberos credential caches and environment variable isolation during database connection establishment. The core technical failure occurs when the application manages connections that are explicitly configured not to utilize delegated credentials from a specific Kerberos user. In these scenarios, pgAdmin attempts to sanitize its execution environment by removing the KRB5CCNAME environment variable, intending to prevent the use of any pre-existing credential cache. However, this action inadvertently triggers a fallback mechanism within the underlying Kerberos library. Instead of rejecting authentication requests that require delegated credentials, the library defaults to using the operating-system account's default credential cache or client keytab associated with the service account running pgAdmin. This behavior creates a significant security gap where the application fails to enforce strict isolation between different user contexts and system-level service accounts.
The operational impact is severe because it allows any authenticated user of the pgAdmin interface, regardless of their intended privileges or designated database identity, to authenticate as the high-privilege Kerberos principal associated with the underlying service account. This occurs through two primary mechanisms depending on the operating system environment. On Linux and Unix-like systems, the libpq library responds to server requests for GSSAPI authentication by presenting the ticket from the default cache of the OS account running pgAdmin. Crucially, this bypass is not prevented even if the connection string explicitly sets gssencmode=disable, indicating a failure in final validation logic before the network handshake occurs. On Windows systems, a similar vulnerability exists where the Security Support Provider Interface (SSPI) utilizes the logon credentials of the service account in an analogous manner, effectively granting unauthorized access to resources protected by that principal's identity.
Furthermore, the vulnerability extends beyond direct database connections through pgAdmin’s integrated tools. When pgAdmin launches psql or other utilities for administrative tasks, it inherits its parent environment variables. If a previous connection attempt left residual credential caches in the environment, these can be passed to subsequent processes. This means that even if a user is not directly exploiting the GSSAPI fallback, they may leverage leftover environmental state from prior sessions to gain unauthorized access or escalate privileges within the database ecosystem. The flaw essentially breaks the principle of least privilege by allowing lower-level application users to impersonate higher-privilege service accounts across multiple connection types and utility executions.
The remediation strategy implemented in version 9.19 addresses these issues through rigorous environment variable management and strict authentication requirement enforcement. Rather than simply removing credential variables, which proved insufficient due to library fallback behaviors, the fix explicitly points KRB5CCNAME and KRB5_CLIENT_KTNAME to a temporary file path that only exists during active Kerberos-authenticated connections involving delegated credentials. This ensures that for all other connection types, no valid cache is available for the libraries to fall back on. Additionally, the update introduces stricter validation logic by applying require_auth=sspi and gssencmode=disable checks directly against the final connection string. These constraints are enforced at a later stage in the connection lifecycle to ensure that non-Kerberos connections cannot inadvertently trigger GSSAPI or SSPI authentication paths. It is important to note that this fix requires libpq version 16 or later, as earlier versions may not support the necessary require_auth parameters for effective enforcement.
From an industry standards perspective, this vulnerability aligns with CWE-250, which describes execution with unnecessary privileges, and CWE-78, improper neutralization of special elements used in an OS command (via environment variable injection). The attack vector leverages ATT&CK technique T1098, specifically account manipulation or credential access via environmental context abuse. Security administrators should prioritize upgrading to pgAdmin 4 version 9.19 or later immediately upon availability. For environments where immediate patching is not feasible, mitigations include ensuring that the service account running pgAdmin has minimal privileges and does not hold high-value Kerberos principals. Additionally, restricting access to the underlying operating system accounts and auditing logs for unexpected GSSAPI authentication successes can help detect exploitation attempts while preparing for the upgrade.