Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A flaw in com.ongres.scram:scram-client allows an attacker capable of performing a TLS man-in-the-middle (MITM) attack to silently downgrade a connection from SCRAM-SHA-256-PLUS (with channel binding) to standard SCRAM-SHA-256 (without channel binding), bypassing strict client-side enforcement policies. Component Breakdown This occurs due to a two-part failure in TlsServerEndpoint when a server presents an X.509 certificate using a modern signature algorithm that lacks traditional WITH naming structures (such as Ed25519 or post-quantum algorithms): 1. The internal hash derivation method fails to parse the algorithm name, swallows the resulting NoSuchAlgorithmException, and silently returns an empty byte array via the deprecated getChannelBindingData() API. 2. The client builder mistakenly interprets this empty byte array as an environmental absence of channel binding data rather than a cryptographic failure, falling back to non-channel-bound authentication. Impact & Scope…
Recommended action: Upgrade to 3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A timing attack vulnerability exists in the SCRAM Java implementation. The issue arises because Arrays.equals was used to compare secret values such as client proofs and server signatures. Since Arrays.equals performs a short-circuit comparison, the execution time varies depending on how many leading bytes match. This behavior could allow an attacker to perform a timing side-channel attack and potentially infer sensitive authentication material. All users relying on SCRAM authentication are impacted. Patches This vulnerability has been patched by replacing Arrays.equals with MessageDigest.isEqual, which ensures constant-time comparison. Users should upgrade to version 3.2 or later to mitigate this issue. Workarounds Because the attack requires high precision and repeated attempts, the risk is limited, but the only reliable mitigation is to upgrade to a patched release (version 3.2 or later). References - Java MessageDigest.isEqual Documentation)
Recommended action: Upgrade to 3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.