CVE-2026-54291 — postgresql
Fix: pgjdbc/pgjdbc@77df98eCVE-2026-54291 is a CWE-636 vulnerability in org.postgresql:postgresql. A fix is available for org.postgresql:postgresql — see the affected versions and patch details below.
Silent channel-binding authentication downgrade via unsupported certificate algorithms
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-54291.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
org.postgresql:postgresqlReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Impact
channelBinding=require connections can be silently downgraded from SCRAM-SHA-256-PLUS (with channel binding) to plain SCRAM-SHA-256 (without it), losing the man-in-the-middle protection the setting is meant to guarantee. An attacker who can intercept the TLS connection triggers the downgrade with a certificate whose signature algorithm has no tls-server-end-point channel-binding hash. Examples are Ed25519, Ed448, and post-quantum algorithms.
Two issues combine in releases 42.7.4 through 42.7.11:
- The bundled
com.ongres.scram:scram-client(3.1 or 3.2) returns an empty byte array instead of failing when it cannot derive the binding hash for such a certificate. This is the library issue tracked as GHSA-p9jg-fcr6-3mhf. - pgJDBC does not enforce
channelBinding=requirewhere it matters.ScramAuthenticatorchecks only that the server advertised a-PLUSmechanism; it neither rejects the empty binding nor checks that the negotiated mechanism uses channel binding. The connection therefore downgrades silently, and would do so even against a fixedscram-client, because the missing enforcement is in pgJDBC's own code.
Only connections that set channelBinding=require are affected. Under the default prefer policy, and under allow or disable, falling back to plain SCRAM is the documented behaviour. Releases before 42.7.4 are unaffected, because they do not support channel binding.
Patches
Fixed in pgJDBC 42.7.12. pgJDBC now enforces channel binding in its own code, independently of the scram-client version:
- Under
channelBinding=require, it fails the connection when no channel-binding data can be extracted from the server certificate, instead of passing an empty value to the SCRAM client. The error names the certificate signature algorithm. - After negotiation, it requires the selected mechanism to use channel binding (a
-PLUSmechanism) wheneverchannelBinding=requireis set, regardless of how negotiation resolved.
Upgrade to 42.7.12 or later.
Workarounds
No pgJDBC setting restores channel-binding enforcement on an affected release; upgrading is the fix.
If you cannot upgrade immediately, verify the server certificate at the TLS layer so that a man-in-the-middle cannot present a substitute certificate. Set sslmode=verify-full with a truststore that contains only your server's CA. This defence is independent of channel binding and blocks the same attacker. Connections that rely on channelBinding=require in place of certificate verification have no equivalent workaround and should upgrade.
References
- GHSA-p9jg-fcr6-3mhf — the related
com.ongres.scram:scram-clientissue (root cause of the empty channel-binding value). scram-client3.3 release (library fix): https://github.com/ongres/scram/releases/tag/3.3- pgJDBC fix in 42.7.12: commit
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.postgresql:postgresql | ≥ 42.7.4&&< 42.7.12 | 42.7.12org.postgresql:postgresql:42.7.12 |
Affected Products
postgresql jdbc driverpostgresqlDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.postgresql:postgresql, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.postgresql:postgresql to 42.7.12 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-54291 is resolved across your whole dependency graph.
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.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat build of Keycloak 26.4.15 | see advisory | RHSA-2026:56520 |
| Red Hat build of Keycloak 26.6.6 | see advisory | RHSA-2026:56523 |
| Red Hat build of Quarkus 3.27.5 | postgresql | RHSA-2026:53643 |
| Red Hat build of Quarkus 3.33.3 | postgresql | RHSA-2026:51653 |
Frequently Asked Questions
Is CVE-2026-54291 in your dependencies?
Find it across Maven, including transitive dependencies.