PostgreSQL PostgreSQL's JDBC driver patches a silent channel-binding downgrade that hits the hardened setups first
PostgreSQL's official JDBC driver shipped a July 6 fix for CVE-2026-54291, a silent SCRAM channel-binding downgrade that only bites connections requiring channel binding over modern Ed25519 or post-quantum certificates. The hardened setups are the exposed ones.
The official PostgreSQL JDBC driver shipped an out-of-band security release on July 6, 2026 for CVE-2026-54291, a flaw that lets a network attacker quietly strip the channel-binding protection off a database login. The revealing part is who it hits: the bug only bites connections that explicitly demand the strongest setting, so the teams most exposed are the ones that opted into hardened authentication in the first place.
What the advisory covers
pgJDBC 42.7.12 fixes a silent downgrade in SCRAM authentication. When a client connects with channelBinding=require, it expects SCRAM-SHA-256-PLUS, the variant that ties the login to the server’s TLS certificate and blocks a man-in-the-middle from relaying credentials. The advisory describes how that guarantee can be dropped without an error: a proxy sitting in the TLS path can steer the handshake back to plain SCRAM-SHA-256, and the driver accepts it as if channel binding were simply unavailable rather than treating the mismatch as an attack. Versions 42.7.4 through 42.7.11 are affected. Releases before 42.7.4 predate channel-binding support and are out of scope, and connections using the default prefer policy, or allow or disable, are unaffected because they never promised channel binding to begin with.
Why the hardened setups are the exposed ones
The failure is a combination of two gaps, and the trigger is modern cryptography rather than a coding slip. The driver bundles com.ongres.scram:scram-client, and in versions 3.2 and earlier that library returns an empty byte array instead of raising an error when it cannot derive the certificate binding hash (tracked upstream as GHSA-p9jg-fcr6-3mhf, rated CVSS 8.2). pgJDBC then compounds it: its authenticator checks only that the server advertised a -PLUS mechanism, without confirming the negotiated exchange actually carried channel-binding data. The condition that makes the hash underivable is a server certificate signed with an algorithm that has no defined tls-server-end-point hash, which is precisely the set of newer algorithms teams are being told to adopt: Ed25519, Ed448, and the post-quantum signature schemes now entering pilots. So the exposure clusters exactly where you would least want it, on connections that set channelBinding=require and terminate TLS with a modern certificate. Doing both of the recommended things at once is what opens the gap.
Where this lands in the market
For most shops the direct blast radius is small. Channel binding is off by default in pgJDBC, and a live man-in-the-middle on a database link is a serious precondition, so this is not an internet-wide emergency in the shape of a Log4Shell. The reason it is worth flagging anyway is what it signals. Channel binding as specified leans on tls-server-end-point, a construction built around the RSA and ECDSA certificates that dominated when the mechanism was written. As the certificate world shifts toward EdDSA and, over the next few years, post-quantum signatures, the assumption that every certificate yields a usable end-point hash stops holding. This CVE is an early, concrete instance of that seam splitting, in one driver, and it is unlikely to be the last client library where the binding layer and the certificate layer disagree quietly. Security-conscious teams that have already moved to Ed25519 server certificates are the leading edge of the problem, not an edge case.
What’s worth watching
- Whether other SCRAM clients carry the same gap. The root defect lives in a shared Java SCRAM library, and the enforcement gap it exposed is an easy assumption to make. Similar downgrade behavior in non-Java drivers or connection poolers would turn a single advisory into a pattern.
- How channel binding adapts to new certificate algorithms. The clean fix is for clients to treat an underivable binding hash as a hard failure, which 42.7.12 does. The larger question is whether the channel-binding spec grows first-class handling for EdDSA and post-quantum certificates rather than leaving each client to fail safely on its own.
- Whether “require” starts meaning require. The practical lesson for developers is that a strict security flag is only as good as the client’s willingness to fail closed. Teams that depend on
channelBinding=requireshould upgrade and treat this as a prompt to check that their other security-required settings actually error out instead of degrading in silence.
The upgrade itself is undramatic: move to pgJDBC 42.7.12, which pulls in the fixed scram-client 3.3 and rejects an empty binding instead of trusting it. The more durable takeaway is that as certificates modernize, the plumbing that binds authentication to them has to keep pace, and a setting that fails open under new inputs is worse than one that was never turned on. Stackmaven will revisit whether this downgrade pattern surfaces in other SCRAM clients on or around October 4.