AsyncHttpClient CVE-2026-107227

Requires that the async-http-client application establishes a WebSocket connection with permessage-deflate compression enabled/negotiated (the description explicitly scopes the flaw to when compression is enabled), and that the remote WebSocket peer is attacker-controlled or an attacker is MITM-positioned on the connection. Because this is a client-side library, exploitation is NOT unauthenticated-server-DoS: the victim app must connect outbound to the malicious endpoint. Limiting factors: the bug does not trigger without compression; the existing webSocketMaxFrameSize and webSocketMaxBufferSize settings do NOT mitigate it (they bound only compressed bytes); affected only in versions 2.2.0 through 3.0.13.

All signals point to an availability-only denial-of-service issue, not a candidate for emergency patching outside WebSocket-dependent services. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5 HIGH) is internally consistent with the description: no confidentiality or integrity impact, only heap exhaustion (CWE-400). No EPSS score, CISA KEV listing, or public POC is present in the provided intelligence, so exploitation status is: no public exploit identified at time of analysis. The high score is driven entirely by the A:H component; this is a genuine but narrow risk rather than a high-CVSS-but-illusory issue. Two limiting factors not captured by the base score must be weighed: (1) async-http-client is a CLIENT library, so the victim application must itself initiate a WebSocket connection to an attacker-controlled (or MITM-positioned) peer rather than passively receive attacker traffic; (2) the flaw only manifests when permessage-deflate compression is enabled on that WebSocket, per the description. AV:N is defensible but the practical attack surface is smaller than a typical network-facing server DoS.

A Java application built on async-http-client (2.2.0-3.0.13) opens a WebSocket to a server with permessage-deflate negotiated. The malicious or compromised server sends a tiny highly-compressible frame (a classic decompression/zip-bomb pattern) that inflates to a huge Netty buffer, and because webSocketMaxFrameSize/webSocketMaxBufferSize only bound compressed bytes, the JVM heap is exhausted and the client crashes. No public exploit is identified at time of analysis, though the technique is well understood and trivial to reproduce.