AsyncHttpClient EUVD-2026-94637

Exploitable only when the victim application uses AsyncHttpClient (before 3.0.12 on 3.x or before 2.16.1 on 2.x) configured to send requests through an HTTP proxy AND the request carries credentials via redirect/authentication handling (Basic or NTLM Authorization). The trigger is a proxy that answers a CONNECT with something other than 200 (e.g., a 401, 407, or 302 rejection), after which the client incorrectly treats the socket as an established tunnel. Exploitation is LIMITED by: the attacker must control or have compromised the HTTP proxy or be able to MITM the client-to-proxy hop (a hostile or compromised proxy, not an arbitrary remote attacker); the application must actually route through a proxy (non-default for many deployments); and only confidentiality is affected (credential disclosure), with Basic recoverable directly and NTLM requiring cracking or relay.

The NVD CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N = 7.5 HIGH) describes a network-reachable, unauthenticated, confidentiality-only flaw, consistent with CWE-319 (cleartext transmission) and the description: origin credentials are written onto a still-plaintext proxy socket after a failed CONNECT. No EPSS score, no CISA KEV listing, and no public exploit were provided in the intelligence, so exploitation status is 'no public exploit identified at time of analysis.' The practical risk is narrower than the raw 7.5 implies: exploitation is not against a default internet-facing service but requires (a) the victim application to route AsyncHttpClient traffic through an HTTP proxy and (b) an attacker who controls or has compromised that proxy, or can MITM the client-to-proxy hop, so a CONNECT can be rejected and an origin request with Authorization solicited. This makes it a credible credential-theft issue for environments using AHC with proxies - especially with Basic or NTLM auth - but a targeted, position-dependent one rather than a mass-exploitable remote flaw. The commit diffs confirm the root cause and fix in detail, raising confidence the vulnerability is real; the main uncertainty is deployment exposure, not technical validity.

A Java application uses AsyncHttpClient configured to reach origin servers through an HTTP proxy and sends requests carrying Authorization (Basic or NTLM) credentials. An attacker who controls or has compromised the proxy (or can intercept the client-to-proxy connection) rejects the CONNECT tunnel request and instead returns a 401 or 302; the client, believing a tunnel exists because the last method was CONNECT, rewrites the origin request and writes its Authorization header onto the still-plaintext proxy socket, where the attacker reads Basic credentials directly or captures NTLM responses for offline cracking or relay. No public proof-of-concept was provided in the intelligence.