CVE-2026-85719 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 2.1.0 until 2.16.1 and 3.0.12, requests using an authenticated SOCKS proxy can expose the proxy's credentials to the origin because NettyRequestFactory and NettyRequestSender attach Proxy-Authorization without confirming that the request is being sent to an HTTP proxy. With preemptive proxy authentication, the header is attached to a plaintext HTTP request, exposing credentials such as directly reversible Basic credentials to the origin. With the default non-preemptive flow, a hostile origin can return a 407 response and ProxyUnauthorized407Interceptor sends the proxy credentials through the existing SOCKS tunnel, including NTLM, Kerberos, and SPNEGO credentials. Releases before 2.1.0 lack SOCKS proxy support. This issue is fixed in versions 2.16.1 and 3.0.12.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
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. A significant security flaw was identified within the proxy authentication handling mechanisms, specifically affecting versions ranging from 2.1.0 up to 2.16.1 in the legacy branch and version 3.0.12 in the newer release line. This vulnerability stems from a fundamental logic error in how the library manages credentials when communicating through an authenticated SOCKS proxy. The core issue lies within the NettyRequestFactory and NettyRequestSender classes, which are responsible for constructing and sending HTTP requests. These components incorrectly attach Proxy-Authorization headers to outgoing requests without verifying whether the target endpoint is actually an HTTP proxy rather than a direct origin server. This oversight creates a scenario where sensitive authentication data intended solely for intermediary network infrastructure can be inadvertently transmitted to external destination servers.
The operational impact of this vulnerability varies depending on the specific authentication mode configured within the application using AsyncHttpClient. In configurations utilizing preemptive proxy authentication, the library attaches Proxy-Authorization headers directly to plaintext HTTP requests before any negotiation with a proxy has occurred or even been necessary for direct connections. Consequently, if an application connects directly to an origin server rather than through a proxy, these credentials are exposed in clear text within the HTTP header fields. This exposure is particularly dangerous when Basic authentication is employed, as its credentials consist of base64-encoded username and password pairs that can be trivially decoded by any party intercepting or observing the network traffic reaching the origin server. Even if TLS encryption protects the transport layer from passive eavesdropping on the wire, a malicious actor with access to the destination server's logs or those capable of performing man-in-the-middle attacks could harvest these credentials for subsequent unauthorized access attempts against the proxy infrastructure.
In scenarios where non-preemptive authentication is used, which is often the default behavior intended to conserve resources by only sending credentials when explicitly challenged, a different but equally severe risk emerges. When an application sends a request through a SOCKS tunnel that has already been established using valid proxy credentials, a hostile origin server can exploit this trust relationship. By returning a 407 Proxy Authentication Required response, the malicious origin tricks the AsyncHttpClient into believing it needs to authenticate with another proxy layer. The library's ProxyUnauthorized407Interceptor then proceeds to send the stored SOCKS proxy credentials through the existing tunnel directly back to the hostile server. This mechanism allows attackers to exfiltrate high-value authentication tokens associated with NTLM, Kerberos, and SPNEGO protocols. Unlike Basic authentication, these enterprise-grade protocols involve complex challenge-response exchanges that can be leveraged for pass-the-hash attacks or other lateral movement techniques within an organization's internal network if the compromised credentials are used elsewhere.
This vulnerability aligns closely with CWE-200, which classifies information exposure resulting from improper handling of sensitive data during communication processes. Furthermore, it relates to CWE-538 regarding insertion of sensitive information into an executable or log file, as well as CWE-798 concerning the use of hardcoded credentials if those proxies are statically configured within application code. From a tactical perspective on the MITRE ATT&CK framework, this flaw facilitates Credential Access techniques such as T1056 Input Capture via keylogging or screen capture is not directly applicable here but rather T1552 Unsecured Credentials where attackers gather unencrypted authentication material from system configurations and local files, specifically through network sniffing or log analysis. The exploitation vector primarily involves Network Sniffing (T1040) if the traffic is intercepted in transit to the origin, or Log Injection/Exfiltration if logs are compromised at the destination server level.
To mitigate this risk, organizations must immediately upgrade their AsyncHttpClient dependencies to version 2.16.1 or higher for legacy systems and version 3.0.12 or higher for modern deployments where these fixes have been implemented. The updated versions correct the logic errors in NettyRequestFactory and NettyRequestSender by ensuring that Proxy-Authorization headers are only attached when a request is explicitly destined for an HTTP proxy, thereby preventing leakage to origin servers during direct connections. Additionally, developers should review their application configurations to ensure they do not rely on preemptive authentication unless absolutely necessary, as this increases the attack surface for credential exposure. Implementing strict network segmentation and monitoring outbound traffic for anomalous Proxy-Authorization headers can provide an additional layer of defense-in-depth against potential exploitation attempts by hostile origins seeking to harvest proxy credentials from vulnerable Java applications.