The Netty SPDY header decoder improperly continues decompressing zlib-compressed header blocks even after the raw header parser has exceeded the configured maxHeaderSize and flagged the frame as truncated. Specifically, a compressed SPDY header block of about 12,253 bytes can declare and inflate a header-name field of 12 MiB, causing compression-amplified resource consumption in the SpdyFrameCodec pipeline. This vulnerability allows a remote unauthenticated attacker to send a small compressed HEADERS frame that expands into a large amount of raw header data, resulting in denial of service via CPU and memory exhaustion. The attack requires a reachable SPDY codec with no upstream limits on compressed frame size or connection rate. The vulnerability is tracked as CVE-2026-55833 and classified under CWE-400 (Uncontrolled Resource Consumption).

An unauthenticated remote attacker can cause a denial of service by sending a specially crafted SPDY HEADERS frame that decompresses into a very large header block, exceeding the maxHeaderSize limit but still causing the decoder to perform expensive decompression and memory allocation. This leads to compression-amplified CPU and memory usage, potentially degrading or crashing the affected Netty server pipeline. There is no impact on confidentiality or integrity, only availability.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. Until a fix is available, mitigate by ensuring that upstream components enforce strict compressed-frame-size and connection-rate limits before frames reach the SpdyFrameCodec. Disabling SPDY support or replacing it with HTTP/2 where possible may also reduce exposure. Monitor for unusual resource consumption patterns related to SPDY traffic.