CVE-2026-54291: Silent Channel-Binding Authentication Downgrade in PostgreSQL JDBC Driver (pgjdbc)

The PostgreSQL JDBC Driver (pgjdbc) is the official open-source Java database connectivity driver for PostgreSQL databases. To protect database connections from Adversary-in-the-Middle (AiTM) attacks, administrators configure the driver with the channelBinding=require connection property. Channel binding provides strong authentication protection by cryptographically binding the outer Transport Layer Security (TLS) tunnel to the inner Simple Authentication and Security Layer (SASL) protocol exchange.

The industry standard mechanism used for PostgreSQL channel binding is tls-server-end-point, specified in RFC 5929. This mechanism functions by taking a cryptographic hash of the server's TLS certificate and incorporating it directly into the SCRAM authentication exchange. If an attacker attempts to intercept the connection by proxying the TLS session with their own certificate, the computed certificate hashes will mismatch, and the authentication flow will fail.

In pgjdbc versions 42.7.4 through 42.7.11, this security guarantee is undermined. When encountering signature algorithms unsupported by the underlying cryptographic libraries for hashing under RFC 5929, the driver silently fails open. The client reverts to standard SCRAM-SHA-256 authentication without channel binding, leaving the connection exposed to interception and credential relay attacks.

The root cause of this vulnerability lies in the interaction between the pgjdbc driver's authentication coordinator, org.postgresql.core.v3.ScramAuthenticator, and the third-party dependency com.ongres.scram:scram-client.

During a connection attempt where channel binding is required, pgjdbc requests the channel-binding hash from the certificate via TlsServerEndpoint.getChannelBindingData(cert). If the target PostgreSQL database server employs a modern certificate signature algorithm, such as Ed25519 or Ed448, the standard Java Cryptography Architecture (JCA) cannot determine an appropriate hash algorithm under RFC 5929 rules. RFC 5929 dictates mapping specific signature algorithms to their corresponding one-way hash functions, but does not define mappings for these newer Edwards-curve signatures.

Instead of raising a cryptographic exception or aborting the handshake, the scram-client library returns an empty byte array (byte[0]). The vulnerable versions of ScramAuthenticator accept this empty array without validation. The underlying SCRAM state machine interprets the empty byte array as a signal that channel-binding data is unavailable for the current context, and dynamically falls back to standard SCRAM-SHA-256 negotiation.

Because the driver fails to verify that the active, negotiated mechanism is actually the channel-bound variant (SCRAM-SHA-256-PLUS), it permits the connection to establish. This sequence bypasses the explicit channelBinding=require policy configuration, leaving the connection vulnerable to a silent downgrade attack.

To visualize the downgrade process, the following diagram illustrates how an intercepting adversary can leverage an unsupported certificate to strip the channel-binding requirement and complete the authentication process without triggering client-side warnings.

Under normal circumstances, if the attacker attempts to intercept the TLS session, the client computes the hash of the attacker's certificate and sends it to the server. The server compares this hash against its own certificate and aborts. By utilizing an Ed25519 certificate, the attacker exploits the client's failure-handling mechanism, prompting the client to submit no channel binding data at all, which the server permits because the client has technically requested the standard non-PLUS authentication mechanism.

The vulnerability was resolved in commit 77df98e4e66c12936ded3478a0954f6f580bad99 by introducing two distinct validation steps within org.postgresql.core.v3.ScramAuthenticator.java. These changes prevent silent downgrade by implementing explicit pre-negotiation and post-negotiation assertions.

The first correction applies immediately after the SASL client initialization. The driver now validates the negotiated mechanism to confirm that a -PLUS variant is in use:

// Code from pgjdbc/src/main/java/org/postgresql/core/v3/ScramAuthenticator.java
 
      // channelBinding=require must never silently downgrade: regardless of how negotiation
      // resolved, the selected mechanism must actually use channel binding (a -PLUS mechanism).
      if (channelBinding == ChannelBinding.REQUIRE && !client.getScramMechanism().isPlus()) {
        throw new PSQLException(
            GT.tr("Channel Binding is required, but the negotiated SCRAM mechanism \"{0}\" "
                + "does not use channel binding.", client.getScramMechanism().getName()),
            PSQLState.CONNECTION_REJECTED);
      }

This check acts as a fail-safe. If negotiations resolve to any standard mechanism that lacks cryptographic channel binding, the client throws a PSQLException and terminates the connection attempt.

The second correction is implemented within the certificate processing phase of getChannelBindingData. It prevents the silent consumption of empty byte arrays:

// Code from pgjdbc/src/main/java/org/postgresql/core/v3/ScramAuthenticator.java
 
            byte[] cbindData = TlsServerEndpoint.getChannelBindingData(cert);
            if (cbindData.length > 0) {
              return cbindData;
            }
            // An empty result means no channel binding hash could be derived from the
            // certificate signature algorithm: for example Ed25519 has no associated hash
            // under RFC 5929 tls-server-end-point. Under REQUIRE this must fail rather than
            // silently downgrade to a non-PLUS mechanism.
            if (channelBinding == ChannelBinding.REQUIRE) {
              throw new PSQLException(
                  GT.tr("Channel Binding is required, but the server certificate signature "
                      + "algorithm \"{0}\" does not support tls-server-end-point channel "
                      + "binding (RFC 5929). Use a server certificate signed with RSA or ECDSA.",
                      cert.getSigAlgName()),
                  PSQLState.CONNECTION_REJECTED);
            }

This patch ensures that if cbindData is empty under a strict channel-binding policy, the driver stops processing. The driver now throws an exception identifying the incompatible certificate signature algorithm, ensuring the system fails closed.

To exploit CVE-2026-54291, an attacker must establish an Adversary-in-the-Middle (AiTM) position between the target Java application (using pgjdbc) and the PostgreSQL server. The attack does not require prior authentication credentials.

The attacker intercepts the initial TLS handshake initiated by the client. The attacker presents a spoofed server certificate signed with an algorithm for which tls-server-end-point cannot compute a hash, such as Ed25519. This certificate can be self-signed or signed by a rogue authority, depending on whether the client performs strict hostname and truststore validation.

Upon receiving this certificate, the vulnerable pgjdbc client invokes TlsServerEndpoint.getChannelBindingData(). The method returns an empty array. The driver, bypassing checks, falls back to the non-PLUS SCRAM authentication flow. The attacker can then transparently proxy the authentication exchange, successfully intercepting or relaying the SCRAM-SHA-256 exchange to the authentic backend server, establishing an authorized session under the victim's identity.

The potential impact of this vulnerability is significant, as it completely negates the protections provided by the channelBinding=require parameter. If exploited, an attacker can bypass mutual authentication protections, perform unauthorized actions on the database, read or alter sensitive records, and potentially gain administrative credentials through relay mechanisms.

Despite the severity, the overall attack complexity remains high. An attacker must have the capability to intercept network traffic on the path between the database client and server, or poison the local network routing. Additionally, if the client implements strict certificate authority verification, the attacker must also possess a valid, trusted certificate utilizing the target unsupported signature algorithm, or find a way to bypass the driver's trust checks.

According to NVD, the CVSS v3.1 score is evaluated at 5.9 (Medium), reflecting the high attack complexity. However, GitHub's CVSS v4.0 assessment assigns a score of 8.2 (High), recognizing that when the required network conditions are met, the integrity of the connection's authentication is severely compromised.

The primary remediation for this vulnerability is upgrading the PostgreSQL JDBC Driver to version 42.7.12 or higher. This version contains the required code-level verification checks to ensure that the driver fails closed when channel binding cannot be negotiated.

In addition to upgrading pgjdbc, developers and administrators should evaluate their transitive dependencies. Upgrading the underlying com.ongres.scram:scram-client library to version 3.3 or higher is recommended, as newer releases of this library address internal deficiencies related to Edwards-curve certificate hashing.

If upgrading the driver is not immediately feasible, organizations can implement operational workarounds. Ensure that all PostgreSQL database servers are configured with certificates signed using RSA or ECDSA signature schemes, which are fully supported under RFC 5929. Organizations must also restrict network paths between database clients and servers using strictly isolated VPC routing, IPsec, or trusted overlay networks to prevent adversaries from establishing the required middleman posture.