The com.ongres.scram:scram-client library versions before 3.3 contain a flaw in the TlsServerEndpoint component where modern certificate signature algorithms (e.g., Ed25519 or post-quantum algorithms) cause the internal hash derivation method to fail parsing the algorithm name. This failure is silently swallowed, returning an empty byte array from the deprecated getChannelBindingData() API. The client then misinterprets this as absence of channel binding data and downgrades authentication from SCRAM-SHA-256-PLUS to SCRAM-SHA-256, bypassing strict client-side channel binding enforcement. This vulnerability only impacts configurations that require strict channel binding enforcement (e.g., channelBinding=require in pgJDBC). Versions 3.3 and later introduce strict exception propagation and explicit policy controls to prevent this silent downgrade.

An attacker capable of performing a TLS man-in-the-middle attack can silently downgrade the authentication mechanism from SCRAM-SHA-256-PLUS (with channel binding) to SCRAM-SHA-256 (without channel binding) in affected versions. This bypasses strict client-side channel binding enforcement policies, weakening the security guarantees of the authentication process. Deployments using default or permissive channel binding policies are not affected by this downgrade. There are no known exploits in the wild at this time.

Upgrade to version 3.3 or later of the com.ongres.scram:scram-client library, which fixes this issue by propagating exceptions properly and providing explicit channel binding policy controls. If using the ScramClient builder API directly, stop using the deprecated TlsServerEndpoint.getChannelBindingData() method and migrate to TlsServerEndpoint.getChannelBindingHash(), which correctly propagates exceptions. Additionally, explicitly set the ChannelBindingPolicy during client construction to enforce strict channel binding requirements rather than relying on implicit behavior.