AsyncHttpClient CVE-2026-107285

Exploitation requires a specific non-default alignment: the application must (1) use AsyncHttpClient older than 3.0.12 / 2.16.1, (2) be configured with an HTTP proxy that uses proxy authentication (Basic or Digest, e.g. preemptive Proxy-Authorization), and (3) actively initiate a plaintext ws:// (not wss://) WebSocket request routed through that proxy. The credential leak flows to the origin WebSocket server, so the beneficiary/attacker is the origin endpoint operator or a party able to observe origin-bound traffic - not an arbitrary internet attacker. Limiting factors: wss:// and plain http:// requests are unaffected; the proxy must require authentication; and only the proxy credential (not application or user data) is exposed. Basic credentials are immediately usable while Digest only yields a replayable/offline-crackable challenge-response.

This is a genuine but moderate-priority information-disclosure flaw (CVSS 5.9), not a high-urgency issue. The input CVSS vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N is internally consistent with the description: no privileges or user interaction on the vulnerable application are needed (PR:N/UI:N), but AC:H correctly reflects that several conditions beyond the attacker's control must align - the application must use AsyncHttpClient with an HTTP proxy configured for proxy authentication AND must initiate a plaintext ws:// WebSocket request through that proxy. The 'attacker' is effectively the origin WebSocket endpoint (or anyone observing origin-bound traffic), since the tunneled upgrade carrying the Proxy-Authorization header reaches the origin rather than the proxy. Confidentiality impact is real (C:H) - Basic proxy credentials are directly recoverable and Digest values can be replayed or cracked offline - with no integrity or availability impact (I:N/A:N), matching CWE-319 (cleartext transmission of sensitive information). No EPSS score, KEV listing, or public POC was provided in the input; absence of these signals, combined with AC:H and the narrow preconditions, indicates this is unlikely to see widespread opportunistic exploitation and is better characterized as a credential-hygiene/targeted risk than an actively weaponized threat.

A Java application uses AsyncHttpClient behind an authenticating HTTP proxy and opens a plaintext ws:// WebSocket connection to an external origin through that proxy. Because ws:// is tunneled via CONNECT but not treated as 'secure,' the WebSocket upgrade request forwarded to the origin includes the proxy's Proxy-Authorization header, so a malicious or compromised origin operator simply reads the inbound request to recover the Basic credential directly (or captures the Digest response for offline cracking/replay). No public exploit code was identified at time of analysis; the fix is confirmed in versions 3.0.12 and 2.16.1.