CVE-2026-107227 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. From 2.2.0 until 3.0.14, WebSocket permessage-deflate decompression is unbounded when compression is enabled. The inbound pipeline aggregates compressed frames before WebSocketClientCompressionHandler inflates them, so webSocketMaxFrameSize and webSocketMaxBufferSize do not bound decompressed output. A malicious WebSocket peer can send a small compressed message that expands to a very large Netty buffer and exhausts JVM heap. This issue is fixed in version 3.0.14.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/08/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 which facilitates real-time bidirectional communication channels. Within the architecture of this library, specifically in versions ranging from 2.2.0 up to but not including 3.0.14, there exists a significant architectural flaw related to how compressed data is handled during WebSocket connections that utilize permessage-deflate compression extensions. This vulnerability stems from an incorrect implementation of buffer management where the inbound pipeline aggregates incoming compressed frames into memory before they are processed by the WebSocketClientCompressionHandler responsible for inflation or decompression operations.
The core technical deficiency lies in the decoupling between frame size limits and actual memory consumption during decompression. The library exposes configuration parameters such as webSocketMaxFrameSize and webSocketMaxBufferSize, which are intended to restrict the amount of data that can be received at any given time. However, due to the design flaw where compressed frames are aggregated prior to inflation, these constraints effectively only limit the size of the incoming compressed payload rather than the resulting decompressed output. Consequently, when compression is enabled, there is no upper bound on the memory allocated for the inflated data structure within the Java Virtual Machine heap space. This creates a scenario where the application's resource consumption is not proportional to the network bandwidth or configured limits but instead depends entirely on the compressibility of the incoming stream.
This architectural weakness enables a severe denial-of-service attack vector, classified under CWE-400 as Uncontrolled Resource Consumption and more specifically aligned with CWE-770: Allocation of Resources Without Limits or Throttling in the context of memory exhaustion. An attacker operating a malicious WebSocket peer can exploit this by transmitting small compressed messages that possess high entropy characteristics designed to expand significantly upon decompression. By sending such crafted payloads, an adversary can cause the Netty buffer underlying the AsyncHttpClient implementation to grow uncontrollably until it exhausts the available JVM heap space. This results in OutOfMemoryError exceptions, leading to application crashes or severe performance degradation for all users connected through that instance, effectively achieving a remote denial of service without requiring authentication or privileged access.
The operational impact of this vulnerability is substantial as it compromises the availability and stability of any Java application relying on AsyncHttpClient versions within the affected range. Since WebSocket connections are often long-lived and used in high-throughput environments such as chat applications, financial trading platforms, or real-time analytics dashboards, a single malicious connection can destabilize the entire service layer. The attack is particularly dangerous because it bypasses standard network-level rate limiting if those limits are based on byte count rather than decompressed size, allowing attackers to trigger resource exhaustion with minimal bandwidth usage. This aligns with MITRE ATT&CK technique T1498: Network Denial of Service, specifically the sub-technique related to flooding or overwhelming resources through inefficient processing logic.
To mitigate this vulnerability and restore secure operation, organizations must upgrade AsyncHttpClient to version 3.0.14 or later where the decompression limits are properly enforced against the inflated output size rather than just the compressed input. In environments where immediate upgrading is not feasible due to dependency constraints, temporary mitigations should focus on restricting WebSocket connections from untrusted sources and implementing strict rate limiting at the network perimeter based on connection duration and message frequency rather than payload volume alone. Additionally, monitoring JVM heap usage trends can help detect potential exploitation attempts early, although this serves only as a detection mechanism rather than a prevention strategy. Ensuring that all third-party libraries are kept up to date with security patches remains the most effective long-term defense against such implementation flaws in asynchronous I/O frameworks.