CVE-2026-107284 in async-http-client
Summary
by MITRE • 10/08/2026
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.12 and 2.16.1, WebSocketHandler.upgrade aborts a handshake whose Sec-WebSocket-Accept value is missing or invalid but continues into pipeline installation and onOpen delivery. Frames coalesced with the invalid 101 response can be decoded and delivered from a peer that did not prove the handshake, although the request future fails and the channel closes. This issue is fixed in versions 3.0.12 and 2.16.1.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/09/2026
The AsyncHttpClient library serves as a critical component for Java-based applications requiring efficient execution of HTTP requests and asynchronous processing of responses, particularly through its WebSocket support capabilities. The vulnerability identified within this library stems from an implementation flaw in the WebSocketHandler.upgrade method, which governs the initial handshake process required to establish a persistent connection between client and server. During a standard WebSocket upgrade sequence, both parties must exchange specific headers, including the Sec-WebSocket-Accept value, to verify that the peer has correctly processed the challenge and possesses the necessary secret key derived from the client's origin nonce. This mechanism is fundamental to preventing unauthorized connections and ensuring that only legitimate peers can proceed with data transmission over the established channel.
The core technical flaw lies in the library's handling of invalid or missing Sec-WebSocket-Accept values during this handshake phase. Specifically, prior to versions 3.0.12 and 2.16.1, if a peer failed to provide a valid acceptance token, indicating that they did not successfully complete the cryptographic verification step, the handler would abort the logical handshake process but erroneously continue with pipeline installation and trigger onOpen delivery events. This creates a state where the application layer believes a connection is established and ready for communication, even though the underlying security check has failed or been bypassed due to malformed input from the remote peer.
This discrepancy leads to significant operational impacts regarding data integrity and unauthorized access potential. Frames coalesced with an invalid 101 Switching Protocols response can be decoded and delivered by the library despite the handshake not being properly proven by the peer. Although the request future ultimately fails and the channel closes, the interim period allows for malicious frames to be processed or interpreted by the application logic before closure occurs. This behavior effectively bypasses authentication controls that rely on WebSocket upgrade validation, potentially allowing an attacker to inject data into a session without proper authorization verification. Such scenarios are particularly dangerous in environments where WebSocket connections carry sensitive business logic or real-time updates dependent on strict peer identity confirmation.
From a classification perspective, this vulnerability aligns with CWE-287 Improper Authentication and CWE-362 Concurrent Execution using Shared Resource with Improper Synchronization of Access Control, as the race condition between handshake failure and pipeline installation allows unauthorized data flow. In terms of attack vectors, it relates to MITM or spoofing techniques where an attacker exploits protocol state inconsistencies to bypass security checks, mapping closely to ATT&CK technique T1078 Valid Accounts if used in conjunction with credential theft, though primarily representing a logic flaw rather than direct exploitation of credentials. The issue highlights the importance of strict adherence to RFC 6455 specifications regarding WebSocket handshake validation before transitioning connection states.
To mitigate this risk, organizations must ensure that all instances of AsyncHttpClient are upgraded to version 3.0.12 or later for major releases and version 2.16.1 or later for legacy branches. These versions contain the necessary patches to correctly halt pipeline installation and prevent onOpen delivery when handshake validation fails. Additionally, developers should implement defense-in-depth strategies by validating WebSocket connections at multiple layers of their architecture, including application-level token verification independent of library defaults. Regular security audits focusing on asynchronous I/O libraries are recommended to identify similar state management flaws in other components that handle network protocols with complex upgrade sequences.