CVE-2026-42587: Netty Decompression DoS Vulnerability

CVE-2026-42587 Overview

CVE-2026-42587 is a denial-of-service vulnerability in Netty, an asynchronous, event-driven network application framework widely used in Java applications. The HttpContentDecompressor component accepts a maxAllocation parameter to cap decompression buffer size and prevent decompression bomb attacks. The limit is enforced for gzip and deflate encodings through ZlibDecoder, but silently ignored when the encoding is br (Brotli), zstd, or snappy. The same flaw affects DelegatingDecompressorFrameListener for HTTP/2 connections. Attackers can submit a compressed payload using one of the unguarded encodings to trigger unbounded memory allocation. The issue is fixed in Netty 4.2.13.Final and 4.1.133.Final.

Critical Impact

Unauthenticated remote attackers can exhaust JVM memory and crash Netty-based services by sending a small Brotli, Zstandard, or Snappy compressed HTTP request that bypasses the configured decompression buffer limit.

Affected Products

• Netty versions prior to 4.2.13.Final
• Netty versions prior to 4.1.133.Final
• Applications using HttpContentDecompressor or DelegatingDecompressorFrameListener with br, zstd, or snappy content encodings

Discovery Timeline

• 2026-05-13 - CVE-2026-42587 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-42587

Vulnerability Analysis

Netty's HTTP decompression layer accepts a maxAllocation parameter intended to bound the memory used while inflating compressed request bodies. The parameter is honored only along the gzip and deflate code path, which routes through ZlibDecoder. When a request arrives with Content-Encoding: br, zstd, or snappy, the decompressor instantiates the corresponding decoder without propagating the allocation cap. The decoder then writes decompressed bytes into composite buffers without an upper bound. An attacker can craft a small compressed payload that expands to gigabytes, exhausting the Java Virtual Machine (JVM) heap. The result is an out-of-memory condition that terminates the worker thread or the entire process. The flaw is classified as Uncontrolled Resource Consumption [CWE-400].

Root Cause

The root cause is inconsistent enforcement of a security control across alternate code paths. The maxAllocation argument is plumbed into ZlibDecoder constructors but is not passed to the Brotli, Zstandard, or Snappy decoders. Developers configuring HttpContentDecompressor reasonably assume the limit applies to every supported encoding. The silent omission converts a documented defense into an encoding-dependent control.

Attack Vector

The attack vector is network-based and requires no authentication or user interaction. An attacker sends an HTTP/1.1 or HTTP/2 request to any Netty-based endpoint that enables content decompression. The request specifies Content-Encoding: br, Content-Encoding: zstd, or Content-Encoding: snappy and carries a decompression bomb body. The server decodes the payload into unbounded memory until the JVM throws OutOfMemoryError. Repeated requests can sustain a denial-of-service condition across a cluster.

No verified exploit code is published. See the GitHub Security Advisory for the upstream technical description.

Detection Methods for CVE-2026-42587

Indicators of Compromise

• Inbound HTTP requests carrying Content-Encoding: br, Content-Encoding: zstd, or Content-Encoding: snappy headers against services that did not previously receive such traffic.
• Java processes terminating with java.lang.OutOfMemoryError: Java heap space shortly after receiving small compressed POST or PUT requests.
• Sudden growth in JVM old-generation heap usage correlated with single inbound connections.

Detection Strategies

• Inspect web application firewall and reverse proxy logs for unusual non-gzip content encodings and flag clients sending high-entropy compressed bodies.
• Correlate JVM garbage collection pauses and heap-exhaustion events with request access logs to identify the originating connection.
• Enumerate dependency manifests (pom.xml, build.gradle) across the estate for Netty versions below 4.2.13.Final and 4.1.133.Final.

Monitoring Recommendations

• Export JVM heap, garbage collection, and direct-buffer metrics to a central observability platform and alert on rapid allocation spikes.
• Log the Content-Encoding header value at the edge and baseline expected encodings per service.
• Track process restart events on Netty-based services and review preceding request samples when restarts cluster in time.

How to Mitigate CVE-2026-42587

Immediate Actions Required

• Upgrade Netty to 4.2.13.Final or 4.1.133.Final across all applications and shaded dependencies.
• Until patched, reject or strip Content-Encoding: br, zstd, and snappy request headers at the upstream load balancer or reverse proxy.
• Restart affected services after patching to ensure the vulnerable classes are unloaded.

Patch Information

The maintainers fixed the issue in Netty 4.2.13.Final and 4.1.133.Final by propagating the maxAllocation limit to the Brotli, Zstandard, and Snappy decompression paths in both HttpContentDecompressor and DelegatingDecompressorFrameListener. Patch details are documented in the Netty GHSA-f6hv-jmp6-3vwv Advisory.

Workarounds

• Configure the reverse proxy to remove or normalize Content-Encoding headers other than gzip and deflate before forwarding requests to Netty.
• Cap per-request body size at the proxy layer so that even uncapped decompression cannot exceed safe memory bounds.
• Disable HTTP content decompression in the Netty pipeline if the application does not require compressed inbound payloads.

# Example: strip unsupported content encodings at an Nginx front end
map $http_content_encoding $safe_content_encoding {
    default        "";
    "gzip"         "gzip";
    "deflate"      "deflate";
}

server {
    listen 443 ssl http2;
    client_max_body_size 10m;

    location / {
        proxy_set_header Content-Encoding $safe_content_encoding;
        proxy_pass http://netty_backend;
    }
}