GHSA-x8v2-478q-2hvg CVE-2026-107227
AsyncHttpClient: Unbounded WebSocket permessage-deflate decompression enables a decompression-bomb denial of service when compression is enabled
- Severity
- 7.5 / 10
- High · CVSS 3.1
- Exploit chance (EPSS)
- 0.43%
- Chance of exploitation in the next 30 days. Higher than 36.92% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-400 Uncontrolled Resource Consumption
- CWE-409 Improper Handling of Highly Compressed Data (Data Amplification)
- Fix
3.0.14- Upgrade org.asynchttpclient:async-http-client to this version or later
Description
Impact
With WebSocket compression enabled, the client inflates permessage-deflate messages with no limit on the decompressed size. It installed Netty's shared WebSocketClientCompressionHandler.INSTANCE, whose inflater is unbounded, and webSocketMaxFrameSize and webSocketMaxBufferSize only bound the compressed bytes, because the frame aggregator sits in front of the inflater.
A malicious or compromised WebSocket server, or anyone on the path of a ws:// connection, can therefore send a message of about 2 MiB that inflates to about 2 GiB, the most a Netty buffer can hold. The client then copies the inflated message again to hand it to the listener. That exhausts the heap of a typically sized JVM. Netty catches the resulting OutOfMemoryError and closes that connection, but while the buffer is live any other allocation in the process can fail too, and a server that keeps sending such messages, on one connection or several, keeps the client at heap exhaustion.
Who is Impacted
Only applications that enable WebSocket compression with setEnablewebSocketCompression(true), which is off by default, and connect to a WebSocket server that is untrusted, compromised, or reached over cleartext ws://.
Affected versions
- 3.x: up to and including 3.0.13
- 2.x: from 2.2.0, when WebSocket compression was added, up to and including 2.16.1
Patches
Fixed in 3.0.14. A new setting, webSocketMaxDecompressedFrameSize (setWebSocketMaxDecompressedFrameSize, or the org.asynchttpclient.webSocketMaxDecompressedFrameSize property), bounds how far a message may inflate, and a message that would go past it fails the connection. It defaults to 128000000 bytes, the same as webSocketMaxBufferSize, so a message is bounded alike whether or not it was compressed; a compressed message that inflates past that, which was accepted before, now fails the connection. With aggregateWebSocketFrameFragments turned off, the bound applies to each frame instead, and fragments are delivered one at a time. Set it lower if you enable compression and do not expect large messages. 0 disables the limit.
The 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14.
Workarounds
Leave WebSocket compression disabled, which is the default.
Details
After the handshake the inbound pipeline is ws-decoder, ws-aggregator, PerMessageDeflateDecoder, ahc-ws: the aggregator, which enforces webSocketMaxBufferSize, sees each message before it is inflated. WebSocketClientCompressionHandler.INSTANCE is built with maxAllocation = 0, which Netty treats as unbounded, and Netty has deprecated it in favour of a constructor that takes a limit. RFC 6455 Section 10.4 asks an implementation to limit the size of a message after reassembly, and under RFC 7692 Section 6.2 the message delivered to the application is the decompressed payload.
This is a different path from the HTTP response decompression fixed under CVE-2026-85721, which never reached the WebSocket pipeline.
Attribution
AI-assisted tools were used to support discovery and analysis.
Affected versions
Maven
| Package | Vulnerable | Fixed in |
|---|---|---|
| org.asynchttpclient:async-http-client | >= 3.0.0, < 3.0.14 |
3.0.14 |
| org.asynchttpclient:async-http-client | >= 2.2.0, <= 2.16.1 |
No fix yet |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
org.asynchttpclient:async-http-client Maven → 3.0.14
- maven
<dependency><groupId>org.asynchttpclient</groupId><artifactId>async-http-client</artifactId><version>3.0.14</version></dependency>- gradle
implementation("org.asynchttpclient:async-http-client:3.0.14")
Severity breakdown
CVSS 3.1 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Weakness
CWE-400: Uncontrolled Resource Consumption
The product does not properly control the allocation and maintenance of a limited resource.
How to prevent it
- Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
- Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
- Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
- Implementation: Ensure that all failures in resource allocation place the system into a safe posture.
CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)
The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-p2jm-6hj6-9rjg AsyncHttpClient: Cookies received over plaintext HTTP can plant, overwrite or delete Secure cookies set over HTTPS | Medium | Also affects org.asynchttpclient:async-http-client |
| GHSA-3wp9-xfwm-rjjf AsyncHttpClient: WebSocket proxy credentials sent to the origin server over a CONNECT tunnel | Medium | Also affects org.asynchttpclient:async-http-client |
| GHSA-mfj3-87qq-382v AsyncHttpClient: Digest authentication cnonce generated with a non-cryptographic random source | Low | Also affects org.asynchttpclient:async-http-client |
| GHSA-jmqq-x5g9-9p2w AsyncHttpClient: Replay to a different host sends the original host request and credentials to the new host | Critical | Also affects org.asynchttpclient:async-http-client |
| GHSA-f9m8-cv68-674w AsyncHttpClient: Cookie Domain attribute is not checked against the public suffix list, so a cookie can be set for co.uk | Medium | Also affects org.asynchttpclient:async-http-client |
| GHSA-rqf5-2wxv-rjf4 AsyncHttpClient: Digest challenge without a usable nonce downgrades to Basic and sends the password in cleartext | High | Also affects org.asynchttpclient:async-http-client |
| GHSA-v2j5-22fr-j62r AsyncHttpClient: Pooled connections can still be shared across NTLM, Negotiate and proxy logins | High | Also affects org.asynchttpclient:async-http-client |
| GHSA-2jwh-9rmr-j4xf AsyncHttpClient CookieStore Silently Overrides Caller's Explicit Cookie Header via setHeader (Bypass of CVE-2024-53990 Fix) | Medium | Also affects org.asynchttpclient:async-http-client |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor