CVE-2026-107284: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-107284 is a WebSocket handshake bypass vulnerability in the AsyncHttpClient (AHC) Java library, where WebSocketHandler.upgrade() fails to terminate processing after detecting an invalid or missing Sec-WebSocket-Accept header. This violates RFC 6455 section 4.1, which requires the client to fail the connection when the handshake check does not pass. Affected versions are 2.x up to and including 2.16.0, and 3.x up to and including 3.0.11. The vulnerability was disclosed on August 9, 2026, and has a CVSS v3.1 base score of 3.7 (Low) (GitHub Advisory).

The root cause is a missing return statement in WebSocketHandler.upgrade() after calling requestSender.abort() when the server's Sec-WebSocket-Accept header is absent or does not match the expected base64 SHA-1 of the client's nonce (CWE-345: Insufficient Verification of Data Authenticity; CWE-670: Always-Incorrect Control Flow Implementation). Because execution falls through, the WebSocket pipeline is installed and onOpen is delivered to the listener even though the handshake was never verified. Any WebSocket frames coalesced with the invalid 101 response in the same TCP read are decoded and delivered to the application from an unverified peer — a scenario exploitable by a cache, transparent intermediary, or an attacker replaying a canned 101 response. The fix, introduced in commits 75a2785 (3.x) and ccdcaa6 (2.x), adds a single return after the abort call to halt further processing (GitHub Commit 3.x, GitHub Commit 2.x).

The primary impact is a low-severity integrity violation: WebSocket frames from an unverified peer can be decoded and delivered to the application listener, enabling cross-protocol confusion or injection of attacker-controlled frame data. Confidentiality and availability are not directly impacted — the request future completes exceptionally, onError is delivered before the spurious onOpen, and the channel is closed immediately after. Applications that key off the returned future or treat onError as terminal are largely unaffected in practice, limiting the real-world blast radius (GitHub Advisory).

There is no known public proof-of-concept exploit, no evidence of in-the-wild exploitation, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.00138, reflecting very low probability of exploitation in the near term. Exploitation requires high attack complexity — the attacker must be positioned as a network intermediary (e.g., a caching proxy or man-in-the-middle) capable of injecting a crafted 101 response with an invalid Sec-WebSocket-Accept and coalesced WebSocket frames (GitHub Advisory, Feedly).

1. Position as intermediary: Place a malicious or compromised network node (e.g., a caching proxy, transparent proxy, or MitM attacker) between the AHC client and the intended WebSocket server.
2. Intercept the WebSocket upgrade request: Capture the client's HTTP Upgrade request, including the Sec-WebSocket-Key header value.
3. Craft a malicious 101 response: Respond with an HTTP 101 Switching Protocols response containing an invalid or absent Sec-WebSocket-Accept header (e.g., Sec-WebSocket-Accept: this-is-not-the-expected-accept).
4. Coalesce WebSocket frames: Append attacker-controlled WebSocket frames immediately after the 101 response headers in the same TCP segment, so they are read together by the AHC client.
5. Frames delivered to listener: On vulnerable AHC versions, the client's WebSocketHandler.upgrade() aborts the future but does not return, causing the pipeline to be upgraded and onOpen to fire; the coalesced frames are decoded and delivered to the application's WebSocketListener from the unverified peer (GitHub Advisory, GitHub Commit 3.x).

• Logs: Application logs showing onOpen fired on a WebSocket connection that also logged an IOException with the message Invalid challenge. Actual: <value>. Expected: <value> — this combination indicates the vulnerable code path was triggered.
• Network: HTTP 101 responses observed in traffic where the Sec-WebSocket-Accept header value does not match the base64 SHA-1 of the corresponding Sec-WebSocket-Key; WebSocket frames coalesced in the same TCP segment as the 101 response from an unexpected or intermediary host.
• Application Behavior: WebSocketListener.onOpen() invoked on connections where onError was also delivered with an IOException referencing an invalid challenge, indicating spurious open events on failed handshakes (GitHub Advisory).

Upgrade to AsyncHttpClient version 3.0.12 (3.x line) or 2.16.1 (2.x line), which add a return statement after the abort call to prevent pipeline installation on a failed handshake. Note that 3.0.12 itself contains a separate issue (GHSA-rqf5-2wxv-rjf4 — Digest downgrade to Basic); users on the 3.x line should upgrade to 3.0.13 or later to address both issues. No configuration-based workaround is available, but applications that exclusively use the returned Future or treat onError as terminal are largely unaffected in practice (GitHub Advisory, AHC v2.16.1 Release, AHC v3.0.12 Release).

The vulnerability was disclosed by the AsyncHttpClient project maintainers via GitHub Security Advisory GHSA-rwhr-j9rv-85f8 on August 9, 2026, as part of a broader security release addressing over a dozen issues in both the 2.x and 3.x lines. No notable independent researcher commentary or significant media coverage has been identified beyond standard vulnerability database aggregation (GitHub Advisory).