Listen to this Post
The AsyncHttpClient (AHC) library is a widely used Java framework that allows applications to execute HTTP requests and process responses asynchronously. This vulnerability, tracked as CVE-2026-85721, resides in the automatic response decompression mechanism on the HTTP/1.1 path. When automatic decompression is enabled — which is the default configuration — the client decompresses response bodies without imposing any limit on the total output size. An attacker who controls a server, compromises a legitimate server, or performs a man-in-the-middle attack can send a small compressed response body that expands exponentially in memory. The compression formats gzip, deflate, and snappy are always available as attack vectors. Brotli and zstd become additional vectors only when their optional codecs are present on the classpath. The root cause lies in ChannelManager.newHttpContentDecompressor(), which creates Netty’s HttpContentDecompressor without any bound. While Netty’s HttpContentDecompressor accepts a maxAllocation parameter, this parameter only limits a single decode step, not the accumulated size of an entire response. An attacker can therefore deliver a decompression bomb as many small chunks, each within the per-chunk limit, but collectively exhausting the client’s heap. The affected versions include 3.x up to and including 3.0.11, and 2.x up to and including 2.16.0. On the HTTP/2 path, a limit has been present from version 3.0.11 onward. However, on versions 3.0.8, 3.0.9, and 3.0.10, the HTTP/2 decompressor is also unbounded, meaning that switching to HTTP/2 does not mitigate the vulnerability on those releases. The fix was introduced in version 3.0.12 on the 3.x line and version 2.16.1 on the 2.x line. The patch works by counting the decompressed bytes produced for each response and failing the response once a configured maximum is exceeded. This ensures that the limit applies to the entire body rather than to any single chunk. For users who cannot immediately upgrade, workarounds are available. On the 3.x line, automatic decompression can be disabled by calling setEnableAutomaticDecompression(false), and decompression can be performed manually with a custom size limit. The 2.x line does not offer such a setting because the decompressor is installed unconditionally. On 2.x, the only option is to remove the inflater handler through httpAdditionalChannelInitializer. On either line, running the client behind a proxy that caps response sizes also provides protection. It is important to note that version 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 authentication and sends the password in cleartext. Users should upgrade to version 3.0.13 to pick up both fixes. The vulnerability is classified under CWE-400 (Uncontrolled Resource Consumption) and has a CVSS score of 7.5, indicating a high severity level.
DailyCVE Form:
Platform: AsyncHttpClient Java
Version: 3.0.11, 2.16.0
Vulnerability: Decompression bomb
Severity: High
date: 2026-09-17
Prediction: 2026-09-17
What Undercode Say
// Disable automatic decompression on 3.x AsyncHttpClientConfig config = new DefaultAsyncHttpClientConfig.Builder() .setEnableAutomaticDecompression(false) .build(); AsyncHttpClient client = new DefaultAsyncHttpClient(config);
// Remove inflater handler on 2.x
config.setHttpAdditionalChannelInitializer((channel) -> {
channel.pipeline().remove("inflater");
});
Verify current AsyncHttpClient version in dependencies mvn dependency:tree | grep async-http-client
Check for vulnerable Netty HttpContentDecompressor usage grep -r "newHttpContentDecompressor" /path/to/async-http-client/
Exploit: (Educational Purposes!)
Create a highly compressed payload (decompression bomb) dd if=/dev/zero bs=1M count=1024 | gzip > bomb.gz Serve the bomb from a malicious server (conceptual) python3 -m http.server 8080 --directory /tmp/bomb The vulnerable client requests the resource and decompresses it without any cumulative size limit, exhausting the Java heap.
// Conceptual illustration: server response with Content-Encoding: gzip // A small compressed body expands to gigabytes in memory on the client. // The client's heap fills until OutOfMemoryError is thrown.
Protection: from this CVE
- Upgrade to AsyncHttpClient 3.0.12 or 2.16.1 immediately. Upgrade to 3.0.13 to also address GHSA-rqf5-2wxv-rjf4.
- On 3.x, call setEnableAutomaticDecompression(false) and implement manual decompression with a strict size limit.
- On 2.x, remove the inflater handler via httpAdditionalChannelInitializer.
- Deploy the client behind a proxy that enforces a maximum response size.
- Monitor heap usage and configure JVM flags to fail fast on excessive allocation.
- Audit dependencies for affected versions using OWASP Dependency-Check or similar tools.
Impact:
A hostile or compromised server, or an attacker who can alter a response in transit, can send a small compressed body that inflates without bound in memory. This exhausts the client’s heap and causes an OutOfMemoryError. The resulting denial of service can destabilize the application using AsyncHttpClient and potentially the underlying host system if shared resources are impacted. The attack requires no authentication and has a low attack complexity, making it a significant availability threat.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
