JDBC 42.7.7 enforces required channel binding across authentication paths

An authentication requirement has to constrain every way a connection can succeed. Checking only the negotiation path that supports the requested protection leaves other authentication methods able to bypass the requirement. PostgreSQL JDBC 42.7.7 fixes this problem for channelBinding=require.

The June 13 PostgreSQL announcement says the driver previously accepted methods without channel binding, including password, MD5, GSS and SSPI authentication. A client configured to insist on channel binding could therefore connect without the protection its configuration appeared to require. The release addresses CVE-2025-49146.

PostgreSQL remains my default relational database, and predictable connection behavior matters as much as SQL behavior in that choice. An explicit requirement should make incompatible negotiation fail. A connection that succeeds under weaker conditions is difficult for an application to distinguish from the protected connection it requested.

Required and preferred express different policies

The security advisory published June 11 lists affected versions as 42.7.4 through versions before 42.7.7. It identifies a possible interception attack against connections whose users believed they required channel binding. The default setting is prefer, so this finding concerns enforcement of a stronger explicit configuration.

The 42.7.7 property definition gives the actual option spellings as disable, prefer and require. Its comment describes channel binding as a way for the server to authenticate itself to the client, supported over SSL with PostgreSQL 11 or later and SCRAM authentication.

These values describe different acceptable outcomes. Preference permits a connection without the preferred capability when negotiation cannot provide it. Requirement excludes that outcome. The defect did not make the default a requirement, and correcting it does not mean that every application automatically starts insisting on channel binding.

SCRAM-PLUS connects authentication to the encrypted connection

The PostgreSQL SASL reference distinguishes SCRAM-SHA-256 from SCRAM-SHA-256-PLUS. The latter includes channel binding and uses the tls-server-end-point binding type. In SASL negotiation, the server advertises mechanisms and the client chooses one it supports.

The reference explains why ordinary SCRAM challenge-response does not alone prevent a fake server from forwarding the exchange. Channel binding includes information about the TLS server certificate in the authentication calculation. That connects the password authentication to the encrypted endpoint instead of allowing the exchange to be passed through unchanged between different endpoints.

The relevant certificate-derived data has a precise definition. RFC 5929 defines tls-server-end-point using a hash of the server certificate as it appears in the TLS Certificate message. The binding is consequently tied to a specified property of the connection, rather than an application-supplied label claiming that encryption exists.

This explains the difference between selecting a mechanism that can bind to TLS and accepting an unrelated authentication path. A configuration requirement needs an enforcement rule before successful connection, even if that path never enters the code that implements SCRAM-PLUS.

The corrected driver checks the authentication message sequence

The 42.7.7 connection implementation applies a guard when the channel-binding option is REQUIRE. For an authentication request other than the SASL sequence, it throws a connection-rejected exception. This check precedes the switch that handles individual authentication methods.

The same guard examines an authentication-success message. If the server reports success without the SASL handshake having completed, the driver rejects the connection. The error explains that required channel binding cannot be satisfied when the server skips authentication.

That second case is significant. A server does not have to request a weaker password mechanism to violate the client's requirement. Skipping the exchange also fails to establish the requested property. The implementation checks successful completion against the expected handshake state, which gives the requirement meaning across both forms of bypass.

This is a reading of the tagged implementation, not a claim that every conceivable proxy configuration has been tested here. The source shows the new acceptance conditions. A useful regression case therefore needs an endpoint that offers an incompatible method, alongside an endpoint that omits authentication. A successful SCRAM-PLUS connection exercises the permitted path, but by itself cannot establish that the driver rejects either prohibited path. Deployment behavior still depends on the endpoint and driver actually participating in the connection.

Certificate verification addresses another part of endpoint identity

The advisory gives sslmode=verify-full as a workaround against interception. The JDBC SSL guide explains that this mode validates the server certificate and checks that its identity matches the requested host. In contrast, sslmode=require requires encryption while accepting server certificates without that identity validation.

Those settings concern TLS establishment. The channelBinding option concerns binding authentication to the encrypted endpoint. Giving both properties explicit values makes the intended connection policy reviewable. For an endpoint with the corresponding certificate trust and SCRAM support configured, a JDBC URL can express both requirements:

jdbc:postgresql://db.example.com/app?sslmode=verify-full&channelBinding=require

This example supplies no credentials and assumes that the client can validate the endpoint's certificate. It is not a replacement for provisioning the trust material or configuring the server's authentication method. Its purpose is to show the exact property spelling for two separate requirements.

I prefer this explicit form because it allows a configuration review to identify the requested behavior without inferring it from a successful login. For this fix, success is meaningful only when the driver has enforced the requirement throughout authentication. An incompatible endpoint should produce a connection error, since accepting it would recreate the policy failure the update corrects.

The affected component is the Java driver distributed as org.postgresql:postgresql. Updating PostgreSQL server binaries alone does not replace that dependency in an application. The June advisory identifies 42.7.7 as the patched version, and the tagged implementation shows the rejection rules that make require effective across the authentication exchange.