CVE-2026-85721: AsyncHttpClient: Unbounded HTTP/1.1 response decompression enables a decompression-bomb denial of service
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
AsyncHttpClientto a version that resolves this vulnerability.Fixed in 2.16.1 - Upgrade
Upgrade
AsyncHttpClientto a version that resolves this vulnerability.Fixed in 3.0.12
Event History
Frequently Asked Questions
Which applications are exposed?
Java applications using AsyncHttpClient's automatic response decompression on HTTP/1.1 are exposed when they receive compressed responses from hostile or compromised servers. Brotli and zstd handling is also affected when their optional codecs are installed.
What does an attacker need to exploit this?
An attacker needs to control a server response or be able to alter a response in transit. They can send a small gzip, deflate, or snappy payload that expands over many chunks until the client exhausts heap memory and raises OutOfMemoryError.
Does switching to HTTP/2 mitigate the issue?
Not on AsyncHttpClient versions 3.0.8 through 3.0.10, where the HTTP/2 decompressor is also unbounded. The provided information only identifies this HTTP/2 condition for those releases.
What should teams do if they cannot patch immediately?
Avoid automatically decompressing responses from untrusted or potentially compromised endpoints where possible. A per-decode-call output limit is not sufficient, because an attacker can distribute expanded content across many small chunks.
How can teams determine whether they need to remediate?
Check whether the application uses AsyncHttpClient automatic response decompression and its deployed version. The issue is fixed in versions 2.16.1 and 3.0.12.