AsyncHttpClient EUVD-2026-94644

The victim application must use AsyncHttpClient's WebSocket feature (WebSocketUpgradeHandler) on a version prior to 3.0.12 or 2.16.1 and initiate a connection to a server the attacker controls or can MITM. The attacker must return a 101 Switching Protocols response with a missing or invalid Sec-WebSocket-Accept value AND pipeline/coalesce WebSocket frames into the same read buffer as that 101 response. Limiting factors: the request future still fails and the channel is closed, so the attacker has only a narrow window in which coalesced frames are decoded and delivered (reflected as AC:H); impact is limited to injection of unverified frames into the listener (no confidentiality or availability impact); and exploitation is impossible unless the client is steered to an attacker-controlled or intercepted endpoint.

This is a genuinely low-priority issue, and the signals are consistent rather than conflicting. The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N, base 3.7) correctly reflects a client-side trust flaw with only low integrity impact and no confidentiality or availability impact. Exploitation requires high complexity (AC:H) because the malicious server must race WebSocket frames coalesced into the same buffer as the invalid 101 response before the channel closes. No EPSS score, KEV listing, or public exploit was supplied; the only 'source code evidence' is the vendor's fix commit plus a regression test (WebSocketHandshakeValidationTest), which is remediation evidence, NOT a weaponized proof-of-concept. There is no CVSS-versus-description conflict: both describe a remote, unauthenticated-peer, low-impact integrity problem. Recommended handling is routine patching during the normal upgrade cycle rather than emergency response. Note: EPSS data is absent, so widespread-exploitation probability cannot be quantified, but the client-side nature and need for attacker-controlled/MITM server position strongly limit real-world risk.

A Java application using AsyncHttpClient opens a WebSocket to an attacker-controlled or man-in-the-middle server. The server returns a 101 Switching Protocols response with a missing or invalid Sec-WebSocket-Accept header but pipelines WebSocket frames into the same buffer; because the vulnerable code continues into pipeline installation and onOpen delivery before closing, those unverified frames are decoded and handed to the application listener. No public exploit exists - only the vendor's fix and a regression test are available.