Description
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.
Published: 2026-10-30
Score: 7.1 High
EPSS: n/a
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Analysis and contextual insights are available on OpenCVE Cloud.

Remediation

No vendor fix or workaround currently provided.

Additional remediation guidance may be available on OpenCVE Cloud.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Fri, 30 Oct 2026 20:15:00 +0000

Type Values Removed Values Added
Description 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.
Title pgAdmin 4: libpq uses the pgAdmin service account's Kerberos credentials
Weaknesses CWE-1188
CWE-522
References
Metrics cvssV3_1

{'score': 8.2, 'vector': 'CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N'}

cvssV4_0

{'score': 7.1, 'vector': 'CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N'}


Subscriptions

No data.

cve-icon MITRE

Status: PUBLISHED

Assigner: PostgreSQL

Published:

Updated: 2026-10-30T19:55:15.101Z

Reserved: 2026-10-25T16:26:16.419Z

Link: CVE-2026-116244

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Received

Published: 2026-10-30T20:17:04.327

Modified: 2026-10-30T20:17:04.327

Link: CVE-2026-116244

cve-icon Redhat

No data.

cve-icon OpenCVE Enrichment

No data.

Weaknesses