GHSA-7grg-jcf7-rpmx: High severity maven/org.asynchttpclient:async-http-client vulnerability

Published Sep 17, 2026
·
Updated

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.

Affected Software

2 affected componentsFixes available
maven/org.asynchttpclient:async-http-client>=2.0.0<=2.16.0
2.16.1
maven/org.asynchttpclient:async-http-client>=3.0.0<=3.0.11
3.0.12

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade maven/org.asynchttpclient:async-http-client to a version that resolves this vulnerability.

    Fixed in 2.16.1
  2. Upgrade

    Upgrade maven/org.asynchttpclient:async-http-client to a version that resolves this vulnerability.

    Fixed in 3.0.12
  3. Upgrade

    Upgrade 2.x line to a version that resolves this vulnerability.

    Fixed in 2.16.1
  4. Upgrade

    Upgrade 3.x line to a version that resolves this vulnerability.

    Fixed in 3.0.12
  5. Upgrade

    Upgrade 3.x line to a version that resolves this vulnerability.

    Fixed in 3.0.13
  6. Configuration

    On 3.x (e.g., 3.0.8, 3.0.9, 3.0.10), disable automatic response decompression via setEnableAutomaticDecompression(false) and decompress manually with a size limit you enforce.

    ChannelManager (HTTP client) setEnableAutomaticDecompression(false) = false
  7. Configuration

    On the 2.x line, there is no setEnableAutomaticDecompression setting; remove the inflater handler through httpAdditionalChannelInitializer (since the decompressor is installed unconditionally).

    2.x (HTTP channel initializer) httpAdditionalChannelInitializer = remove inflater handler
  8. Compensating control

    Run the client behind a proxy that caps response sizes to bound decompressed responses delivered in transit.

Event History

Sep 17, 2026
Advisory Published
via GitHub·05:18 PM
Data Sourced
via GitHub·05:18 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Who is exposed to this issue?

Applications using async-http-client with automatic response decompression enabled are exposed; this setting is enabled by default. Exploitation requires a hostile or compromised server, or an attacker able to modify responses in transit.

2

Which response encodings can be used to trigger memory exhaustion?

gzip, deflate, and snappy are always available vectors. Brotli and zstd are additional vectors only when their optional codecs are present on the classpath.

3

Is switching to HTTP/2 a viable mitigation?

Not on versions 3.0.8, 3.0.9, or 3.0.10, where the HTTP/2 decompressor is also unbounded. From 3.0.11 onward, the HTTP/2 path has its own limit.

4

What can be done if an upgrade cannot be applied immediately?

On the 3.x line, disable automatic decompression with setEnableAutomaticDecompression(false) and perform decompression manually. The provided data does not specify an equivalent workaround for the 2.x line.

5

Which versions contain the fix?

The issue is fixed in 3.0.12 for the 3.x line and 2.16.1 for the 2.x line. The fix enforces a configured maximum across the total decompressed response body and fails responses that exceed it.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203