NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
Not in CISA KEV

CVE-2026-116244 — pgadmin4

Fix: pgadmin-org/pgadmin4@145e511

CVE-2026-116244 is a CWE-522 vulnerability. A fix is available — see the affected versions and patch details below.

pgAdmin 4: libpq uses the pgAdmin service account's Kerberos credentials

Published
Updated
Affected
1 product
Patched
See advisory
Exploits
None indexed
Exploitation data as of Nov 4, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs20th percentile — riskier than 20% of all scored CVEsHighest risk
0.00%0.26%0.52%0.78%0.3%0.3%Nov 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

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.

Affected Products

1 product · 1 configurations
Application
pgadmin 4pgadmin
< 9.19
range

Detection & mitigation playbook

Vulnerability
  1. Detect

    Identify every host running the affected component and compare the installed build against the fixed version below — for source-built or distro-packaged software the version string, not a lockfile, is the source of truth (`dpkg -l`, `rpm -q`, or the binary's own `--version`).

  2. Fix

    Upgrade the affected component to the fixed release for CVE-2026-116244, or apply your distribution's backported patch — distro builds are often patched at an older version number, so check your vendor's advisory rather than the upstream version alone.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Frequently Asked Questions

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
O3 Security · Impact-Aware SCA

Is CVE-2026-116244 in your dependencies?

Find it across your dependency tree, including transitive dependencies.

CVE-2026-116244: pgadmin4