Summary
PostgreSQL JDBC Driver: Silent channel-binding authentication downgrade via unsupported certificate algorithms
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
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.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is CVE-2026-54291? CVE-2026-54291 is a high-severity security vulnerability in org.postgresql:postgresql (maven), affecting versions >= 42.7.4, < 42.7.12. It is fixed in 42.7.12.
- Which versions of org.postgresql:postgresql are affected by CVE-2026-54291? org.postgresql:postgresql (maven) versions >= 42.7.4, < 42.7.12 is affected.
- Is there a fix for CVE-2026-54291? Yes. CVE-2026-54291 is fixed in 42.7.12. Upgrade to this version or later.
- Is CVE-2026-54291 exploitable, and should I be worried? Whether CVE-2026-54291 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-54291 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-54291? Upgrade
org.postgresql:postgresqlto 42.7.12 or later.