CVE-2026-85721 in async-http-client
Summary
by MITRE • 09/17/2026
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 2.16.1 and 3.0.12, automatic response decompression on the HTTP/1.1 path uses ChannelManager.newHttpContentDecompressor() to install Http1ContentDecompressor without a cumulative output-size limit. A hostile or compromised server, or an attacker who can alter a response in transit, can send a small gzip, deflate, or snappy response that expands across chunks until the client exhausts its heap and raises OutOfMemoryError; brotli and zstd are also affected when their optional codecs are present. In versions 3.0.8 through 3.0.10, the HTTP/2 decompressor is also unbounded, so switching protocols does not mitigate the issue on those releases. A limit applied to each decode call is insufficient because the response can be delivered as many small chunks, so the fixed implementation tracks total decompressed bytes for the whole response. This issue is fixed in versions 2.16.1 and 3.0.12.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The AsyncHttpClient library serves as a critical component in Java-based ecosystems, enabling applications to execute HTTP requests with high concurrency through asynchronous processing of responses. A significant security flaw exists within the automatic response decompression mechanism for both HTTP/1.1 and HTTP/2 protocols across specific version ranges. In versions 2.0.0 up to 2.16.1 and 3.0.8 up to 3.0.12, the library utilizes ChannelManager.newHttpContentDecompressor() to instantiate decompressors such as Http1ContentDecompressor without implementing a cumulative output-size limit for the decompressed data. This architectural oversight creates a severe vulnerability where an attacker can exploit the lack of bounds checking on the total size of decompressed content rather than just individual chunk sizes.
The operational impact of this flaw is a resource exhaustion attack, specifically targeting the Java Virtual Machine heap space. An adversary controlling or compromising a server, or one capable of intercepting and altering responses in transit via a man-in-the-middle position, can craft malicious HTTP responses containing compressed payloads like gzip, deflate, snappy, brotli, or zstd that exhibit extreme expansion ratios. By sending small initial chunks that expand significantly upon decompression across multiple subsequent chunks, the attacker forces the client to allocate increasing amounts of memory until it exhausts its available heap space. This results in an OutOfMemoryError, effectively causing a Denial of Service against the application using AsyncHttpClient and potentially destabilizing the underlying host system if shared resources are impacted.
This vulnerability is classified under CWE-400, which covers Uncontrolled Resource Consumption, as the application fails to properly control the allocation or retention of limited resources such as memory. From an offensive security perspective, this aligns with MITRE ATT&CK technique T1498, Network Denial of Service, specifically within the context of resource exhaustion via compression bombs. The flaw persists across both HTTP/1.1 and HTTP/2 protocols in versions 3.0.8 through 3.0.10 because the HTTP/2 decompressor also lacks unbounded limits, meaning that switching between protocol versions does not mitigate the risk during those specific releases. Previous mitigation attempts involving fixed limits per decode call are insufficient because they do account for the cumulative nature of chunked responses where a single logical response can be delivered as many small chunks, thereby bypassing per-chunk checks.
To remediate this vulnerability, organizations must upgrade AsyncHttpClient to version 2.16.1 or later, which includes fixes that track total decompressed bytes for the entire response and enforce appropriate limits. For systems unable to immediately patch, implementing a reverse proxy with strict size limitations on upstream responses can provide an additional layer of defense by truncating excessively large decompressed bodies before they reach the application server. Additionally, monitoring heap usage metrics and setting up alerts for OutOfMemoryError events can aid in early detection of such attacks during the transition period to patched versions.