CVE-2026-85716 in async-http-client
Summary
by MITRE • 09/17/2026
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 3.0.8 until 3.0.12, processScramAuthenticationInfo and processAuthenticationInfo compute the SCRAM ServerSignature or Digest rspauth verification result but log a mismatch and still deliver the response as authenticated. On a non-TLS or compromised transport, a peer that has not proved knowledge of the shared secret can therefore be accepted as the server. The fix rejects a present invalid value and computes Digest rspauth from the Authorization parameters actually sent, but verification remains unenforced when the value is absent, the sent parameters cannot be recovered, or Digest uses qop=auth-int. This issue is fixed in version 3.0.12.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The AsyncHttpClient library serves as a critical component for Java-based applications requiring efficient execution of HTTP requests and asynchronous processing of responses. Within the specific versions ranging from 3.0.8 to 3.0.12, a significant authentication bypass vulnerability exists in the handling of SCRAM (Salted Challenge Response Authentication Mechanism) protocols. The core technical flaw resides within the processScramAuthenticationInfo and processAuthenticationInfo methods, which are responsible for verifying server signatures during the authentication handshake. Specifically, these functions compute the expected ServerSignature or Digest rspauth value to validate that the peer possesses knowledge of the shared secret. However, despite detecting a mismatch between the computed signature and the one provided by the remote party, the implementation erroneously logs this discrepancy as an error but proceeds to deliver the response as if authentication had been successfully completed. This logic error effectively neutralizes the integrity check intended to prevent impersonation attacks.
The operational impact of this vulnerability is severe in environments where transport layer security such as TLS is not enforced or has been compromised through man-in-the-middle techniques. An attacker positioned on the network path can intercept communications and manipulate the authentication exchange. Because the library accepts a mismatched signature, an adversary who does not possess the correct shared secret can successfully impersonate the server to the client application. This undermines the fundamental security guarantees of mutual authentication, allowing for potential data exfiltration, session hijacking, or injection of malicious payloads under the guise of a legitimate service endpoint. The vulnerability aligns with CWE-287, which describes Improper Authentication, as well as CWE-345 regarding Insufficient Verification of Data Authenticity. From an offensive security perspective, this behavior facilitates MITM attacks and is consistent with ATT&CK technique T1078, Valid Accounts, where attackers leverage compromised or forged credentials to gain unauthorized access.
The remediation strategy involves upgrading the AsyncHttpClient library to version 3.0.12 or later, which corrects the logic by rejecting invalid signature values rather than accepting them after logging an error. The updated implementation ensures that the Digest rspauth is computed strictly from the Authorization parameters actually transmitted during the handshake, thereby enforcing verification integrity. However, security practitioners must remain aware of residual risks in specific edge cases even within the patched version. Verification remains unenforced if the authentication value is entirely absent from the request, if the sent parameters cannot be recovered due to state loss or parsing errors, or when the Digest protocol utilizes qop=auth-int quality of protection settings which may have different handling characteristics for integrity checks. Consequently, organizations should not only apply the patch but also enforce TLS encryption end-to-end and implement strict input validation to mitigate any remaining attack surface associated with missing parameters or specific authentication modes.