Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessLure/await client HTTP request to attacker-controlled or in-path server
-
DeliveryReturn small gzip/deflate/snappy compressed body with Content-Encoding
-
ExploitUnbounded decompressor inflates across chunks
-
ExecutionClient heap exhausted, OutOfMemoryError
-
ImpactCalling Java service crashes (DoS)
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource consumption limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the AsyncHttpClient-based application to send an HTTP request to a server the attacker controls, has compromised, or can rewrite responses for in transit (an active/MITM position) - this is a client-side library, so there is no directly listening service to attack. The vulnerable path is automatic response decompression: the server returns a compressed body via Content-Encoding of gzip, deflate, or snappy (all affected by default), or brotli/zstd (affected only when those optional codecs are on the classpath). Affects AHC 2.0.0 up to but not including 2.16.1, and 3.x before 3.0.12; on releases 3.0.8 through 3.0.10 the HTTP/2 decompressor is also unbounded, so switching to HTTP/2 does not mitigate. No authentication or user interaction is needed on the client side, but realistic risk is limited to deployments that make outbound calls to untrusted, attacker-influenceable, or user-specified URLs. |
| Impact | This is a genuine but bounded availability risk. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) correctly captures a network-reachable, low-complexity, unauthenticated flaw with pure availability impact (no confidentiality or integrity loss) - the client is crashed via OutOfMemoryError, nothing is read or altered. The 7.5 score is defensible and I concur. However, the CVSS network vector understates the real precondition: this is a CLIENT-side library flaw, so the 'attacker' must be the server the client chooses to talk to (hostile or compromised) or an in-path adversary who can rewrite responses - the victim application must initiate the connection. That is not the same threat surface as a remotely reachable server bug, so the practical exploitability is lower than a naive reading of AV:N/PR:N suggests. No EPSS score, no CISA KEV listing, and no public exploit code are provided in the intelligence, so exploitation status is 'no public exploit identified at time of analysis.' The mechanism (a decompression bomb - small compressed body inflating without a cumulative limit) is well understood and the fix commits are public, which modestly lowers the effort to build a POC, but there is no evidence of active exploitation. Net: a real, patch-worthy DoS for services that make outbound HTTP calls through AHC to untrusted or attacker-influenceable endpoints, but not a drop-everything emergency absent KEV/EPSS signals. |
| Exploit ScenarioDerived | A Java service uses AsyncHttpClient to fetch data from an external HTTP endpoint (e.g., a webhook target, third-party API, or URL supplied via SSRF-style user input). An attacker who controls or has compromised that endpoint - or who sits in the network path - returns a tiny gzip/deflate/snappy (or brotli/zstd where those codecs are present) response that AHC auto-decompresses across many small chunks with no cumulative size cap, inflating until the client JVM exhausts its heap and throws OutOfMemoryError, taking down the calling service. No public exploit code is identified, but the fix commits publicly reveal the mechanism. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 17, 2026
Heap exhaustion in AsyncHttpClient (AHC) 2.0.0 through 2.16.0 and 3.x before 3.0.12 allows any server the client calls - or anyone able to rewrite a response in transit - to kill the client JVM by returning a small gzip, deflate, or snappy body that inflates without bound across chunks until the process raises OutOfMemoryError. The vulnerable path is automatic response decompression on HTTP/1.1, and on releases 3.0.8 through 3.0.10 the HTTP/2 decompressor is unbounded as well, so switching protocols does not mitigate; brotli and zstd are also affected when those optional codecs are on the classpath. This is an availability-only issue (CVSS 7.5, AV:N/AC:L/PR:N/UI:N/A:H) with no public exploit identified at time of analysis, and realistic exposure is limited to deployments that make outbound HTTP requests to untrusted, attacker-influenceable, or user-supplied URLs.
RemediationAI
Vendor-released patch: upgrade to AsyncHttpClient 2.16.1 (for the 2.x line) or 3.0.12 (for the 3.x line); per the advisory at https://github.com/AsyncHttpClient/async-http-client/security/advisories/GHSA-7grg-jcf7-rpmx, the fixed implementation tracks total decompressed bytes across the whole response and enforces a hardcoded default ceiling of 268435456 bytes (256 MiB), while deliberately leaving Netty's per-call maxAllocation at 0. Because the patch is only available by version upgrade, teams that cannot move immediately should reduce exposure rather than rely on configuration: if the application does not need transparent decoding, disabling automatic decompression (or omitting/restricting Accept-Encoding so responses arrive uncompressed) removes the vulnerable path, at the cost of higher bandwidth and possible breakage in code that assumes decoded bodies; where a max-decompressed-response-size setting is exposed by the deployed release, do not treat it as a fix, since a limit applied per decode call cannot bound a response delivered as many small chunks and a non-zero Netty maxAllocation is itself unsafe with the brotli decoder. Additionally, restrict outbound requests to an allowlist of trusted hosts and avoid fetching user-supplied URLs, which block the hostile-server and SSRF-style vectors; keep TLS certificate validation strict to complicate in-transit response tampering, though this does nothing against a compromised origin; and on the JVM consider a bounded heap with -XX:+ExitOnOutOfMemoryError so an exhausted client fails fast and is restarted instead of hanging, accepting the availability hit of a supervised restart.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 3 packages in maven, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-400 (Uncontrolled Resource Consumption) in AHC's Netty-based response pipeline: on the HTTP/1.1 path, ChannelManager.newHttpContentDecompressor() installed Netty's Http1ContentDecompressor without any bound on the cumulative inflated output of a response, so a hostile server can stream a tiny compressed payload that expands across many Content chunks until the JVM heap is exhausted. The subtlety - called out explicitly in the upstream fix - is that Netty's own maxAllocation constructor parameter is not a substitute: it becomes the maxCapacity of the buffer produced by a single decode() call, with no counter spanning calls, and the HTTP codec hands the decompressor at most AsyncHttpClientConfig.getHttpClientCodecMaxChunkSize() bytes at a time (8 KiB by default), so an ordinary compression ratio never trips it no matter how large the total response grows. Setting a non-zero maxAllocation is also actively harmful on Netty 4.1: HttpContentDecompressor.newContentDecoder forwards it to BrotliDecoder(int), which treats the value as an input buffer size and eagerly allocates a native DecoderJNI.Wrapper of exactly that size in handlerAdded - so a 256 MiB 'ceiling' would cost 256 MiB of direct memory for every Content-Encoding: br response, including empty bodies. The patched implementation instead introduces org.asynchttpclient.netty.handler.BoundedHttpContentDecompressor, which leaves Netty's maxAllocation at 0 and installs its own counter inside the per-response decoder pipeline that tracks total decompressed bytes for the whole response and fails the request with a DecompressionException once the configured ceiling is exceeded; the default ceiling is hardcoded to 268435456 bytes (256 MiB) rather than read through AsyncHttpClientConfigDefaults, so a typo in configuration cannot break every connection on the event loop. Relevant upstream commits are 5ee2841cbf268bba4a200578be3938ccfc6cc6d6, 663a1a91757904b22cfe37e2e6049f1f8ea6ae59, e1871a19972fb496be1b8ac6be11d79e22ff2162, and e9f2f7423e0f6503f529656f2955a1317e56ba14, tracked by advisory GHSA-7grg-jcf7-rpmx.
Know when Java gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Network-delivered malicious response, low complexity, no auth or interaction on the client side; pure heap-exhaustion DoS so C:N/I:N/A:H, matching vendor 7.5.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
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.
Blast Radius
ecosystem impact- 24 maven packages depend on org.asynchttpclient:async-http-client (15 direct, 9 indirect)
Ecosystem-wide dependent count for version 3.0.0.
Technical POC Analysis
CWE-400 (Uncontrolled Resource Consumption), with CWE-409 (Improper Handling of Highly Compressed Data) as the amplifying mechanism.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
AsyncHttpClient (AHC) versions 2.0.0 through 2.16.0 and 3.x before 3.0.12 contain a heap exhaustion flaw that allows any server the client contacts-or an attacker able to modify responses in transit-to crash the client JVM by returning a compressed response that expands without bound, causing OutOfMemoryError and service unavailability. This unauthenticated, network-based denial-of-service affects Java applications that make outbound HTTP requests to untrusted or user-supplied URLs, potentially disrupting critical business services and violating availability SLAs. No public exploit has been identified, but no vendor patch is available yet, so organizations must assess exposure and implement interim mitigations.
No vendor-released patch identified at time of analysis. Interim mitigations: disable automatic response decompression in AsyncHttpClient; enforce strict response size limits at the application or network layer; restrict outbound HTTP connections to trusted hosts via egress allowlisting; for versions 3.0.8 through 3.0.10, avoid HTTP/2 and remove optional brotli/zstd codecs from the classpath; monitor for vendor patch and upgrade when available.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m
Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti
Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent
Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug
JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up
Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up
The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow
Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla
The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during
EUVD-2026-81907
GHSA-7grg-jcf7-rpmx
NVD
CVE.org
EPSS
VulDB
Exploit-DB