CVE-2026-55833: Netty SPDY Header DOS Vulnerability

CVE-2026-55833 Overview

CVE-2026-55833 is a denial-of-service vulnerability in Netty, an asynchronous event-driven network application framework used to build protocol servers and clients. The flaw resides in the SPDY header decoding path, where SpdyFrameCodec continues inflating zlib-compressed header blocks even after the raw header parser exceeds maxHeaderSize and marks the frame as truncated. A remote peer can transmit a small compressed HEADERS block that decompresses into significantly larger raw header data, producing compression-amplified CPU load and allocation churn on the target. The issue affects versions prior to 4.1.136.Final and 4.2.16.Final and is categorized under [CWE-400] Uncontrolled Resource Consumption.

Critical Impact
Remote unauthenticated attackers can exhaust CPU and memory resources on any Netty-based service that accepts SPDY traffic, causing service degradation or full denial of service.

Affected Products

Netty versions prior to 4.1.136.Final
Netty versions prior to 4.2.16.Final
Applications and frameworks embedding vulnerable Netty releases using the SPDY codec

Discovery Timeline

2026-07-21 - CVE-2026-55833 published to NVD
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-55833

Vulnerability Analysis

The vulnerability arises in Netty's SPDY frame codec, which decodes header blocks compressed with zlib. The SPDY protocol uses shared compression dictionaries that produce high compression ratios for typical HTTP headers, meaning a few kilobytes of compressed input can inflate into megabytes of raw header bytes.

Netty enforces a configurable maxHeaderSize limit on decoded headers. However, SpdyFrameCodec continues driving the zlib inflater even after the parser detects that the raw header data has exceeded this ceiling and marks the frame truncated. The decoder does not short-circuit inflation once truncation is signaled, so CPU work and heap allocations continue for the full compressed payload.

The result is a classic decompression bomb pattern applied to a protocol-level control channel. An attacker only needs to send small crafted HEADERS frames to consume disproportionate server resources.

Root Cause

The root cause is a missing early-exit condition in the SPDY header decompression loop. The maxHeaderSize threshold is treated as a parser-level guard rather than an inflation-level guard, so the zlib stream continues to be processed after truncation. The upstream fix stops feeding the inflater and releases intermediate buffers once the truncated state is reached.

Attack Vector

Exploitation requires network access to a service that negotiates SPDY using vulnerable Netty. No authentication or user interaction is needed. The attacker constructs a HEADERS frame whose zlib-compressed payload expands into a very large raw header stream, then submits it across one or more connections. Each frame forces the server to spend CPU cycles inflating data that will be discarded, and to allocate transient buffers that pressure the garbage collector.

java

// Netty upstream patch context (io.netty.handler.codec.compression)
// Additional bounds checks added to decompression paths in the security release.
if (++rleAccumulator == 4) {
    if (bwtBytesDecoded >= bwtBlockLength) {
        throw new DecompressionException(
            "malformed RLE: run-length byte missing at end of block");
    }
    // Accumulation complete, start repetition
    int rleRepeat = decodeNextBWTByte() + 1;
    this.rleRepeat = rleRepeat;
}
// Source: https://github.com/netty/netty/commit/5b68c61f37aa4a3045cba624cbea239655c9003b

Detection Methods for CVE-2026-55833

Indicators of Compromise

Sustained high CPU utilization on Netty worker threads correlated with inbound SPDY traffic.
Elevated young-generation garbage collection frequency and short-lived large byte[] allocations in JVM heap dumps.
SPDY HEADERS frames with unusually high compression ratios or repeated truncated-header log entries from SpdyFrameCodec.

Detection Strategies

Enable Netty debug logging on the SPDY codec and alert on repeated header truncation events from a single peer.
Instrument application metrics to track per-connection decompression ratios and flag ratios exceeding a defined threshold.
Correlate JVM CPU and allocation metrics with source IP address to isolate abusive clients.

Monitoring Recommendations

Monitor upstream load balancers for a low request rate paired with spiking backend CPU, a signature of amplification attacks.
Track dependency inventory for netty:netty versions below 4.1.136.Final and 4.2.16.Final using software composition analysis.
Review network telemetry for SPDY negotiations, which are uncommon in modern deployments and warrant scrutiny.

How to Mitigate CVE-2026-55833

Immediate Actions Required

Upgrade Netty to 4.1.136.Final or 4.2.16.Final on all affected services and rebuild dependent artifacts.
Audit application dependency trees for transitive Netty inclusions, including shaded copies inside third-party libraries.
Disable the SPDY codec on services that do not require it, since SPDY has been deprecated in favor of HTTP/2.

Patch Information

The fix is available in Netty releases 4.1.136.Final and 4.2.16.Final. Technical details are documented in the Netty GitHub Security Advisory GHSA-mvh2-crg5-v77c. The corrective commits are 5b68c61 and bb2ff68.

Workarounds

Remove SpdyFrameCodec from server pipelines and terminate SPDY at an upstream proxy that enforces payload limits.
Lower maxHeaderSize and connection concurrency limits to reduce the ceiling on per-connection resource consumption.
Apply network-level rate limiting and connection quotas per source address on services that must remain exposed.

bash

# Maven dependency override to force the patched Netty version
mvn dependency:tree -Dincludes=io.netty
mvn versions:use-dep-version \
  -Dincludes=io.netty:netty-all \
  -DdepVersion=4.1.136.Final \
  -DforceVersion=true