CVE-2026-85721: AsyncHttpClient: Unbounded HTTP/1.1 response decompression enables a decompression-bomb denial of service
Impact With automatic response decompression enabled (the default), the HTTP/1.1 path decompresses response bodies with no limit on the total output size. A hostile or compromised server, or an attacker who can change a response in transit, can send a small compressed body that inflates without bound in memory, exhausting the client's heap and causing an OutOfMemoryError. gzip, deflate and snappy are always available as vectors; brotli and zstd apply only when those optional codecs are on the classpath.
Affected versions 3.x: up to and including 3.0.11 2.x: up to and including 2.16.0
The HTTP/2 path carries its own limit from 3.0.11 onward. On 3.0.8, 3.0.9 and 3.0.10 the HTTP/2 decompressor is also unbounded, so on those versions switching to HTTP/2 is not a mitigation.
Patches Fixed in 3.0.12 on the 3.x line and in 2.16.1 on the 2.x line. The fix counts the decompressed bytes produced for each response and fails the response once the configured maximum is exceeded, so the limit applies to the whole body rather than to any single chunk.
Workarounds On 3.x, disable automatic decompression (setEnableAutomaticDecompression(false)) and decompress manually with your own size limit. The 2.x line has no such setting; the decompressor is installed unconditionally, so the only option there is to remove the inflater handler through httpAdditionalChannelInitializer. On either line, running the client behind a proxy that caps response sizes also works.
Details ChannelManager.newHttpContentDecompressor() created Netty's HttpContentDecompressor without any bound, and Netty's own maxAllocation parameter limits a single decode step rather than the accumulated size of a response, so it cannot bound a decompression bomb delivered as many small chunks. The fix tracks the accumulated decompressed size per response instead.
Note that 3.0.12 is itself affected by a separate issue, GHSA-rqf5-2wxv-rjf4, where a Digest challenge the client cannot read downgrades to Basic and sends the password in cleartext. Upgrade to 3.0.13 to pick up both fixes.
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.asynchttpclient:async-http-clientto a version that resolves this vulnerability.Fixed in 2.16.1 - Upgrade
Upgrade
maven/org.asynchttpclient:async-http-clientto a version that resolves this vulnerability.Fixed in 3.0.12 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 2.16.1 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.0.12 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.0.13 - Configuration
On 3.x, disable automatic response decompression (setEnableAutomaticDecompression(false)) and decompress manually with your own size limit.
AsyncHttpClient setEnableAutomaticDecompression(false) = false - Configuration
On 2.x, since the decompressor is installed unconditionally and there is no such setting, remove the inflater handler via httpAdditionalChannelInitializer.
AsyncHttpClient (2.x) httpAdditionalChannelInitializer = remove inflater handler - Compensating control
Run the client behind a proxy that caps response sizes to a maximum, mitigating decompression-bomb payloads.
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.