CVE-2026-42587

What it actually does

This vulnerability allows a remote, unauthenticated attacker to bypass Netty’s configured decompression memory limit for HTTP request bodies. Netty’s HttpContentDecompressor and HTTP/2 DelegatingDecompressorFrameListener correctly enforce maxAllocation limits for gzip and deflate, but prior to Netty 4.2.13.Final and 4.1.133.Final the same limit is ignored for Brotli, Zstandard, and Snappy content encodings. A specially crafted compressed payload using Content-Encoding: br, zstd, or snappy can decompress into a much larger in-memory buffer than intended, causing excessive heap allocation and potentially an out-of-memory condition. The practical technical result is remotely triggerable denial of service against applications, gateways, proxies, or services that use vulnerable Netty HTTP decompression paths and accept compressed request bodies.

Why it matters to the business

Successful exploitation can make affected services slow, unstable, or completely unavailable by exhausting memory. This can interrupt customer-facing APIs, internal service-to-service communication, streaming endpoints, gateways, and applications built on Netty. Because exploitation is network-accessible, low-complexity, and requires no authentication, internet-facing services that automatically decompress HTTP or HTTP/2 request bodies are the highest priority. Although EPSS is currently low and there is no CISA KEV listing or known ransomware association, the issue has a high availability impact and affects a widely used Java networking framework, so downstream exposure may be significant in applications and frameworks that embed Netty transitively.

How an attack unfolds

An attacker first identifies an HTTP or HTTP/2 endpoint backed by a vulnerable Netty version where inbound compressed request bodies are accepted and automatically decompressed. Instead of using gzip or deflate, where Netty enforces the configured maxAllocation limit, the attacker sends a request with Content-Encoding set to br, zstd, or snappy. The request body is crafted as a compression bomb: small on the wire but very large after decompression. Because vulnerable Netty versions do not apply the decompression allocation limit to these encodings, the service allocates memory until heap pressure becomes severe. Repeated requests, concurrent requests, or a single highly amplified payload can trigger garbage collection churn, request failures, process termination, container restarts, or full service outage. The same pattern can be used over HTTP/2 against code paths using DelegatingDecompressorFrameListener.

How to fix it

Upgrade Netty to a fixed release: 4.2.13.Final or later for the 4.2.x line, or 4.1.133.Final or later for the 4.1.x line. Because Netty is frequently included as a transitive dependency, review both direct and indirect dependencies in Java build files and dependency lock files. If immediate upgrade is not possible, mitigate by disabling automatic decompression for untrusted inbound request bodies, blocking or rejecting Content-Encoding values of br, zstd, and snappy at reverse proxies or application gateways where not required, enforcing strict request body size limits before decompression where feasible, applying per-request memory limits, rate limiting unauthenticated endpoints, and ensuring service supervisors restart failed processes safely. Do not rely solely on Netty’s maxAllocation setting in vulnerable versions for Brotli, Zstandard, or Snappy payloads.

How to confirm the fix worked

Confirm the deployed Netty version is 4.2.13.Final or later, or 4.1.133.Final or later, across all packaged applications and containers. Validate using dependency inspection tools such as Maven dependency:tree, Gradle dependencies, SBOM scans, container image scans, and runtime classpath inspection. Confirm there are no older netty-codec-http or netty-codec-http2 artifacts bundled in application archives. Where safe, test with controlled compressed request bodies using Content-Encoding: br, zstd, and snappy to verify that decompressed payload limits are enforced or that unsupported encodings are rejected. Also confirm that reverse proxy and gateway policies reject unnecessary compressed request encodings and that memory use remains bounded during negative testing.

Typical attack path

1. Discover an application, API gateway, proxy, or service using vulnerable Netty HTTP or HTTP/2 decompression.
2. Confirm the endpoint accepts compressed request bodies or compressed HTTP/2 data frames.
3. Prepare a highly compressed payload that expands to a large size when decoded with Brotli, Zstandard, or Snappy.
4. Send the payload with a header such as Content-Encoding: br, Content-Encoding: zstd, or Content-Encoding: snappy.
5. Repeat the request or send concurrent requests to increase memory pressure.
6. Cause excessive heap allocation, garbage collection churn, out-of-memory errors, process crashes, or service restarts.

How to detect it

Look for evidence of attempted or successful denial-of-service activity rather than data theft. Relevant sources include HTTP access logs, reverse proxy logs, API gateway logs, application logs, Java exception logs, container orchestration events, JVM metrics, garbage collection logs, and host memory telemetry. Search for inbound requests using Content-Encoding values of br, zstd, or snappy, particularly large request counts, unusual request body compression ratios, repeated requests from the same IP address, or bursts preceding service degradation. Correlate those requests with HTTP 500/502/503/504 responses, increased latency, JVM heap exhaustion, long garbage collection pauses, process exits, pod/container OOMKilled events, and Java OutOfMemoryError stack traces involving Netty HTTP decompression classes. For HTTP/2 services, review gateway and application telemetry for compressed DATA frames and failures around Netty HTTP/2 decompression handling. There are no public reports of active exploitation or named threat actors in the provided data, so detection should focus on behavioral indicators: abnormal compressed inbound traffic followed by memory exhaustion or service instability.

• Content-Encoding: br
• Content-Encoding: zstd
• Content-Encoding: snappy
• content-encoding: br
• content-encoding: zstd
• content-encoding: snappy
• java.lang.OutOfMemoryError: Java heap space
• java.lang.OutOfMemoryError
• OutOfMemoryError
• OOMKilled
• GC overhead limit exceeded
• io.netty.handler.codec.http.HttpContentDecompressor
• io.netty.handler.codec.http2.DelegatingDecompressorFrameListener
• netty-codec-http
• netty-codec-http2
• HTTP/2 stream error
• 503 Service Unavailable
• 502 Bad Gateway
• 504 Gateway Timeout

What your security team should do

• Inventory applications, services, gateways, and container images that include Netty, especially netty-codec-http and netty-codec-http2.
• Prioritize internet-facing and unauthenticated HTTP/HTTP/2 endpoints that accept compressed request bodies.
• Upgrade affected Netty dependencies to 4.2.13.Final or later, or 4.1.133.Final or later.
• Search dependency trees and SBOMs for transitive vulnerable Netty versions, not just direct dependencies.
• Temporarily block or reject inbound Content-Encoding: br, Content-Encoding: zstd, and Content-Encoding: snappy where business functionality does not require them.
• Add or verify request size limits, rate limits, memory limits, and autoscaling/restart safeguards for exposed services.
• Monitor for spikes in HTTP 5xx responses, Java heap usage, garbage collection pauses, OutOfMemoryError events, and container restarts correlated with compressed inbound requests.
• Review historical access logs for unusual volumes of Brotli, Zstandard, or Snappy encoded request bodies, especially from single sources or against unauthenticated endpoints.