Summary
pgAdmin 4 can unintentionally use the operating-system service account's Kerberos credentials when connecting to PostgreSQL, rather than the identity selected by the pgAdmin user. In affected configurations, this may allow a user to authenticate to a server as the service account or expose another user's delegated credential context to tools launched by pgAdmin.
pgAdmin 4 can unintentionally use the operating-system service account's Kerberos credentials when connecting to PostgreSQL, rather than the identity selected by the pgAdmin user. In affected configurations, this may allow a user to authenticate to a server as the service account or expose another user's delegated credential context to tools launched by pgAdmin.
Affected context
The issue arises when pgAdmin 4 handles connections that are not intended to use a Kerberos user's delegated credentials but removes the credential-cache environment references. Kerberos libraries or Windows SSPI may then fall back to credentials associated with the operating-system account running pgAdmin. The risk is relevant in server deployments, on systems using Kerberos or SSPI authentication, and where pgAdmin launches psql or related utilities with inherited environment variables.
The issue arises when pgAdmin 4 handles connections that are not intended to use a Kerberos user's delegated credentials but removes the credential-cache environment references. Kerberos libraries or Windows SSPI may then fall back to credentials associated with the operating-system account running pgAdmin. The risk is relevant in server deployments, on systems using Kerberos or SSPI authentication, and where pgAdmin launches psql or related utilities with inherited environment variables.
Exploit preconditions
- Attack surface: pgAdmin 4 connection handling and tools launched from its environment
- Required access: Ability to use or initiate a pgAdmin-managed database connection; broader system access is not necessarily required
- Trigger point: A PostgreSQL connection that negotiates GSSAPI or SSPI authentication
- Why exploitation is possible: Credential-cache or keytab variables may be absent or inherited, allowing the authentication library to select the service account's credentials instead of enforcing the identity requested by the pgAdmin user
- Additional condition: In some workflows, a psql process may inherit a credential cache associated with another connecting user
- Attack surface: pgAdmin 4 connection handling and tools launched from its environment
- Required access: Ability to use or initiate a pgAdmin-managed database connection; broader system access is not necessarily required
- Trigger point: A PostgreSQL connection that negotiates GSSAPI or SSPI authentication
- Why exploitation is possible: Credential-cache or keytab variables may be absent or inherited, allowing the authentication library to select the service account's credentials instead of enforcing the identity requested by the pgAdmin user
- Additional condition: In some workflows, a psql process may inherit a credential cache associated with another connecting user
Why this happens
The underlying flaw is ambiguous credential selection during authentication. When pgAdmin removes or fails to isolate Kerberos credential references, the authentication stack can fall back to the operating-system account's default credential cache or client keytab; on Windows, SSPI can use the service account's logon context.
This maps primarily to CWE-522: Insufficiently Protected Credentials, because credential sources are not sufficiently isolated or constrained to the intended user and connection. It also relates to CWE-1188: Insecure Default Initialization, because authentication behavior falls back to ambient operating-system credentials when an explicit connection-specific credential context is unavailable. Disabling GSSAPI encryption alone does not necessarily prevent authentication through GSSAPI or SSPI.
The underlying flaw is ambiguous credential selection during authentication. When pgAdmin removes or fails to isolate Kerberos credential references, the authentication stack can fall back to the operating-system account's default credential cache or client keytab; on Windows, SSPI can use the service account's logon context.
This maps primarily to CWE-522: Insufficiently Protected Credentials, because credential sources are not sufficiently isolated or constrained to the intended user and connection. It also relates to CWE-1188: Insecure Default Initialization, because authentication behavior falls back to ambient operating-system credentials when an explicit connection-specific credential context is unavailable. Disabling GSSAPI encryption alone does not necessarily prevent authentication through GSSAPI or SSPI.
Potential impact
- A user could authenticate to a PostgreSQL server as the pgAdmin service account's Kerberos principal.
- Database authorization decisions could be made for the wrong identity.
- Access granted to the service account could be misused by less-privileged pgAdmin users.
- A launched psql process could use another user's delegated credential cache.
- Audit records could associate activity with an unintended Kerberos principal.
- A user could authenticate to a PostgreSQL server as the pgAdmin service account's Kerberos principal.
- Database authorization decisions could be made for the wrong identity.
- Access granted to the service account could be misused by less-privileged pgAdmin users.
- A launched psql process could use another user's delegated credential cache.
- Audit records could associate activity with an unintended Kerberos principal.
General mitigation guidance
Mitigation generally focuses on making credential selection explicit, isolated, and fail-closed.
Common defensive patterns include:
- Pointing Kerberos credential-cache and client-keytab variables to connection-specific files that exist only during an explicitly authenticated Kerberos workflow.
- Applying final connection-string policies that reject GSSAPI and SSPI for connections that are not intended to use those mechanisms.
- Treating
gssencmode=disableas an encryption control rather than as a complete authentication restriction. - Preventing psql and other child processes from inheriting unrelated users' credential-cache environment variables.
- Separating service-account credentials from interactive-user credentials and avoiding ambient credential discovery.
- Running pgAdmin with the minimum operating-system and database privileges required.
- Ensuring failed or ambiguous credential selection cannot silently fall back to a service account.
Mitigation generally focuses on making credential selection explicit, isolated, and fail-closed.
Common defensive patterns include:
- Pointing Kerberos credential-cache and client-keytab variables to connection-specific files that exist only during an explicitly authenticated Kerberos workflow.
- Applying final connection-string policies that reject GSSAPI and SSPI for connections that are not intended to use those mechanisms.
- Treating
gssencmode=disableas an encryption control rather than as a complete authentication restriction. - Preventing psql and other child processes from inheriting unrelated users' credential-cache environment variables.
- Separating service-account credentials from interactive-user credentials and avoiding ambient credential discovery.
- Running pgAdmin with the minimum operating-system and database privileges required.
- Ensuring failed or ambiguous credential selection cannot silently fall back to a service account.
How teams detect issues like this
Detection can combine code, configuration, and runtime review.
- Use static analysis and dependency-aware checks to identify authentication code that clears credential variables or relies on default Kerberos and SSPI discovery.
- Review connection construction for explicit restrictions on authentication mechanisms and verify that policies are applied to the final connection string.
- Inspect process environments for inherited
KRB5CCNAME,KRB5_CLIENT_KTNAME, or equivalent credential references. - Audit whether psql and other child processes inherit interactive users' credential caches.
- Monitor PostgreSQL and Kerberos logs for connections whose authenticated principal differs from the identity selected in pgAdmin.
- Enforce configuration policies requiring explicit credential sources and disallowing ambient service-account authentication for interactive connections.
- Automated code-review and policy tools may help flag unsafe credential inheritance and fallback behavior.
Detection can combine code, configuration, and runtime review.
- Use static analysis and dependency-aware checks to identify authentication code that clears credential variables or relies on default Kerberos and SSPI discovery.
- Review connection construction for explicit restrictions on authentication mechanisms and verify that policies are applied to the final connection string.
- Inspect process environments for inherited
KRB5CCNAME,KRB5_CLIENT_KTNAME, or equivalent credential references. - Audit whether psql and other child processes inherit interactive users' credential caches.
- Monitor PostgreSQL and Kerberos logs for connections whose authenticated principal differs from the identity selected in pgAdmin.
- Enforce configuration policies requiring explicit credential sources and disallowing ambient service-account authentication for interactive connections.
- Automated code-review and policy tools may help flag unsafe credential inheritance and fallback behavior.
