CVE-2026-54291: Silent channel-binding authentication downgrade via unsupported certificate algorithms

Published Jul 6, 2026
·
Updated

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:

1. 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. 2. pgJDBC does not enforce channelBinding=require where it matters. ScramAuthenticator checks only that the server advertised a -PLUS mechanism; 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 fixed scram-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 -PLUS mechanism) whenever channelBinding=require is 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-client issue (root cause of the empty channel-binding value). - scram-client 3.3 release (library fix): https://github.com/ongres/scram/releases/tag/3.3 - pgJDBC fix in 42.7.12: commit

Other sources

pgjdbc is an open source postgresql JDBC Driver. In releases 42.7.4 through 42.7.11, 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 can trigger the downgrade with a certificate whose signature algorithm has no tls-server-end-point channel-binding hash, because the bundled com.ongres.scram:scram-client returns an empty byte array instead of failing and pgJDBC ScramAuthenticator checks only that the server advertised a PLUS mechanism, without rejecting the empty binding or checking that the negotiated mechanism uses channel binding. This issue is fixed in version 42.7.12.

MITRE

Affected Software

3 affected componentsFixes available
pgjdbc pgjdbc>=42.7.4<=42.7.11
PostgreSQL PostgreSQL JDBC driver>=42.7.4<42.7.12
maven/org.postgresql:postgresql>=42.7.4<42.7.12
42.7.12

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade maven/org.postgresql:postgresql to a version that resolves this vulnerability.

    Fixed in 42.7.12
  2. Upgrade

    Upgrade pgJDBC to a version that resolves this vulnerability.

    Fixed in 42.7.12
  3. Configuration

    Set sslmode=verify-full with a truststore that contains only your server's CA.

    pgJDBC connection string / SSL/TLS sslmode = verify-full
  4. Compensating control

    If you cannot upgrade immediately, verify the server certificate at the TLS layer so a man-in-the-middle cannot present a substitute certificate.

Event History

Jul 6, 2026
CVE Published
via MITRE·06:55 PM
Data Sourced
via MITRE·06:55 PM
DescriptionWeakness
Data Sourced
via NVD·07:17 PM
RemedyDescriptionSeverityWeaknessAffected Software
Jul 21, 2026
Advisory Published
via GitHub·05:47 PM
Data Sourced
via GitHub·05:47 PM
DescriptionWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-54291?

CVE-2026-54291 has a severity score of 8.2, indicating a high risk.

2

How do I fix CVE-2026-54291?

To fix CVE-2026-54291, you need to apply the available patches for pgjdbc versions 42.7.4 through 42.7.11.

3

What type of attack does CVE-2026-54291 protect against?

CVE-2026-54291 can leave connections vulnerable to man-in-the-middle attacks due to the downgrade of channel binding.

4

Which versions of pgjdbc are affected by CVE-2026-54291?

pgjdbc versions 42.7.4 through 42.7.11 are affected by CVE-2026-54291.

5

What does channelBinding=require mean in the context of CVE-2026-54291?

In the context of CVE-2026-54291, channelBinding=require indicates a setting meant to enforce secure connections but is compromised by the vulnerability.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203