CVE-2026-93394: libmongoc SCRAM client nonce-validation bypass
A flaw in libmongoc's SCRAM authentication implementation caused the client to continue the authentication handshake and transmit the client proof even when a nonce mismatch was detected in the server's first message. An unauthorized party with a man-in-the-middle position could exploit this by injecting a crafted server-first-message containing a controlled salt and low iteration count, then capturing the resulting client proof to perform offline password cracking. This vulnerability is mitigated by TLS, which is standard in production deployments.
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Clients using libmongoc SCRAM authentication are exposed when an unauthorized party can place themselves between the client and server and alter the server’s first SCRAM message. Deployments protected by TLS are mitigated; TLS is standard in production deployments.
What does an attacker need to do to exploit it?
The attacker needs a man-in-the-middle position and must inject a crafted server-first message with a controlled salt and low iteration count after a nonce mismatch. They can then capture the client proof that libmongoc sends despite detecting the mismatch and use it for offline password cracking.
What is the practical impact of successful exploitation?
Successful exploitation exposes a captured client proof for offline password-cracking attempts. The provided information does not indicate direct modification of data or service availability impact.
What can be done if patching is not immediately possible?
Use TLS for connections using libmongoc SCRAM authentication. TLS mitigates the man-in-the-middle message injection required for exploitation.