Netty CVE-2026-55833

The target application must have Netty's SPDY support active - specifically SpdyFrameCodec / the SPDY handlers configured in the channel pipeline and accepting SPDY connections from remote peers. Given AV:N/AC:L/PR:N/UI:N, no authentication or user interaction is required against such an endpoint, so exploitation is remote and unauthenticated. The primary limiting factor is deployment: SPDY is a deprecated protocol and is not enabled in Netty by default for typical HTTP/2 or HTTP/1.1 servers, so applications that never configure the SPDY codec are not exposed. There is no platform or version gating beyond running a Netty release earlier than 4.1.136.Final or 4.2.16.Final with SPDY header decoding reachable by untrusted clients.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) is internally consistent with the description: a remote, unauthenticated peer with low complexity and no user interaction can trigger the condition, and impact is confined to availability with no confidentiality or integrity effect - appropriate for a DoS. No EPSS score, KEV entry, or POC was provided, so exploitation probability signals are absent; treat this as no public exploit identified at time of analysis and not confirmed actively exploited. The real-world priority is moderated by a key gating factor not reflected in the raw CVSS: exploitation requires the target application to actually deploy Netty's SPDY codec, and SPDY is a deprecated protocol rarely enabled in modern deployments. Therefore, while CVSS rates this High and Netty is extremely widely deployed, the exploitable attack surface is narrow - this is a genuine but conditional DoS rather than a broadly weaponizable flaw, and should be prioritized higher only where SpdyFrameCodec is confirmed in the pipeline.

An attacker connects to an internet-facing service that has Netty's SPDY codec enabled and sends a single small, highly compressible zlib HEADERS block crafted to expand well beyond maxHeaderSize. Because the decoder keeps inflating after the truncation limit is hit, each cheap request forces expensive decompression and large allocations on the server; repeating this across connections exhausts CPU and heap and denies service to legitimate users. No public POC was provided, but the amplification technique is straightforward given the fix details.