Listen to this Post
The AsyncHttpClient (AHC) library for Java provides asynchronous HTTP request execution. From version 3.0.8 through 3.0.11, the client computes the server’s verification value for SCRAM (ServerSignature) and Digest mutual authentication (rspauth) but fails to act on a mismatch. If the value is present and does not verify, the client only logs it and still delivers the response to the application as a successful, authenticated result. This means a server that never proved knowledge of the shared secret is accepted, and the client loses its ability to detect an impostor. Over TLS the real server always returns a valid value, so the issue is inert; it matters over a non-TLS transport, or when the transport is already compromised, where it removes the client’s only signal that the peer does not know the secret. Earlier 3.0.x releases are not affected because neither SCRAM nor the Digest Authentication-Info handling existed before 3.0.8; the 2.x line is also unaffected as it has no SCRAM support and does not implement Digest mutual authentication. The vulnerability is fixed in 3.0.12, where a present but invalid ServerSignature or rspauth now fails the request instead of being logged and ignored, on both the origin and proxy paths. However, verification is only enforced when the value is present and the parameters the client sent can be recovered; a response that omits the Authentication-Info header entirely, or carries the header without a recognisable verification parameter, is still accepted. An impostor that simply omits the value is therefore still accepted. The two schemes differ on malformed input: SCRAM aborts when the data parameter is present but is not valid base64, whereas Digest treats an unparseable rspauth as absent and accepts the response. Verification is also skipped when the parameters the client sent cannot be recovered from its own Authorization header, in which case the exchange is delivered rather than failed. In the auth interceptor, processScramAuthenticationInfo and processAuthenticationInfo computed the verification value and compared it, but did not stop the response from being delivered; both now abort the exchange when the value is present and does not verify. The Digest expected value must be computed over the parameters actually sent on the wire, which the client recovers from its own Authorization header, because the realm carried on the response future is rebuilt for header emission and does not hold the values that were sent. Note that 3.0.12 is itself affected by a separate issue, GHSA-rqf5-2wxv-rjf4, where a Digest challenge the client cannot read downgrades to Basic and sends the password in cleartext; upgrade to 3.0.13 to pick up both fixes. This fix does not cover Digest exchanges negotiated with qop=”auth-int”; under auth-int the rspauth signs the response entity-body, which has not been read when the header is processed, so the expected value cannot be derived at that point, and the client logs a warning and delivers the response without enforcing mutual authentication. A peer that controls the challenge can select this deliberately by offering qop=”auth-int” alone, which switches mutual authentication off for the whole exchange; offering auth,auth-int does not work because the client prefers auth. Verification under auth-int needs to be deferred until the body has been read, which is tracked separately as GHSA-qhv6-3pmh-95q4. The CVSS v3.1 score is 3.7 (Low), with vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N.
DailyCVE Form
Platform: AsyncHttpClient
Version: 3.0.8-3.0.11
Vulnerability: Not verified
Severity: Low
date: 2026-09-17
Prediction: 2026-09-17
What Undercode Say:
Check the current dependency version:
mvn dependency:tree | grep async-http-client
Inspect the vulnerable interceptor code (simplified representation):
// processScramAuthenticationInfo or processAuthenticationInfo
if (computedSignature != null && !computedSignature.equals(receivedSignature)) {
logger.error("Server signature mismatch!"); // only logs
// does not throw or abort
}
// response is delivered as authenticated
Verify if your project is affected by the related GHSA advisories:
grep -r "GHSA-rqf5-2wxv-rjf4|GHSA-qhv6-3pmh-95q4" .
Exploit: (Educational Purposes!)
An attacker positioned on a non-TLS network path can impersonate a legitimate server without possessing the shared secret. The attacker sets up a rogue server that accepts the client’s SCRAM or Digest authentication request and returns a response containing an invalid ServerSignature or rspauth. Because the affected AsyncHttpClient versions only log the mismatch and still deliver the response as authenticated, the client application treats the rogue server as legitimate. This allows the attacker to hijack the session, exfiltrate data, or inject malicious payloads under the guise of a trusted service endpoint. The attack is only viable when TLS is not enforced or has been compromised via a man-in-the-middle technique.
Protection: from this CVE
Upgrade to AsyncHttpClient version 3.0.13, which includes the fix for CVE-2026-85716 and the separate issue GHSA-rqf5-2wxv-rjf4. If immediate upgrade is not possible, enforce TLS end-to-end to prevent man-in-the-middle attacks, as the vulnerability is inert over TLS. Additionally, monitor for responses that omit the Authentication-Info header, as an impostor may exploit the residual limitation where absent verification values are still accepted.
Impact:
The vulnerability breaks mutual authentication in SCRAM and Digest exchanges. A client using an affected AsyncHttpClient version can be tricked into accepting a server that does not know the shared secret. This undermines the fundamental security guarantee of mutual authentication, potentially leading to data exfiltration, session hijacking, or injection of malicious payloads under the guise of a legitimate service endpoint. The impact is limited to environments where TLS is not enforced or has been compromised, and the CVSS score is Low (3.7) due to the high attack complexity and limited integrity impact.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
