CVE-2026-55833

What it actually does

This is a remotely triggerable denial-of-service flaw in Netty's SPDY header decoding path. Before Netty 4.1.136.Final and 4.2.16.Final, SpdyFrameCodec can continue inflating zlib-compressed SPDY HEADERS blocks even after the decoded header data exceeds maxHeaderSize and the frame has been marked truncated. A remote unauthenticated peer can therefore send relatively small compressed header payloads that expand into much larger raw header data, causing excessive CPU consumption, memory allocation churn, garbage collection pressure, and potential service unavailability. The issue does not directly provide confidentiality or integrity impact, but it can significantly degrade or interrupt availability for applications that expose SPDY handling through affected Netty versions.

Why it matters to the business

Services built on affected Netty versions and accepting SPDY traffic may be forced into high CPU and memory usage by remote clients, leading to latency spikes, failed requests, container restarts, autoscaling events, or full service outages. Because exploitation is network-reachable, requires no authentication, and public exploit maturity is listed as available, internet-exposed or high-volume protocol gateways should treat this as an availability risk even though it is not listed in CISA KEV and has a low current EPSS score.

How an attack unfolds

An attacker identifies a service that uses a vulnerable Netty release with SPDY support enabled or reachable through protocol negotiation. The attacker establishes a network connection and sends crafted SPDY HEADERS frames containing zlib-compressed header blocks designed to be small on the wire but to inflate into very large raw header data. The raw header parser detects that maxHeaderSize has been exceeded and marks the frame truncated, but the vulnerable decoder continues inflating the compressed block. Repeating this across one or many connections forces the target process to spend disproportionate CPU time decompressing and allocating buffers, causing garbage collection pressure, event loop delays, request timeouts, and possible process or container failure. The attack can be sustained with modest bandwidth because the compression ratio amplifies the resource cost on the server side.

How to fix it

Upgrade Netty to a fixed release: 4.1.136.Final or later for the 4.1.x line, or 4.2.16.Final or later for the 4.2.x line. For Red Hat-packaged Netty, apply the vendor fix identified in RHSA-2026:47172 for codec-http. Rebuild and redeploy all applications, containers, shaded JARs, and downstream components that bundle vulnerable Netty artifacts; dependency overrides may be needed where Netty is pulled transitively. If immediate patching is not possible, disable SPDY support where feasible, block SPDY protocol negotiation at edge proxies/load balancers, enforce strict request/header limits before traffic reaches Netty, rate-limit abnormal connection patterns, and ensure resource limits and autoscaling protections are in place. Mitigations should be considered temporary because the vulnerable decompression behavior remains present until Netty is upgraded.

How to confirm the fix worked

Confirm dependency resolution shows Netty 4.1.136.Final or later, or 4.2.16.Final or later, for all relevant Netty modules, especially codec-http/SPDY-related components. For Red Hat deployments, verify the package advisory RHSA-2026:47172 has been applied. Inspect built artifacts for embedded or shaded vulnerable Netty classes rather than relying only on top-level dependency manifests. Validate that services no longer negotiate or process SPDY if SPDY has been disabled as a mitigation. In a controlled test environment, send oversized compressed SPDY header blocks and confirm the service rejects or closes the frame/connection without sustained CPU spikes, excessive allocation, or event-loop stalls. Monitor production after remediation for reduced CPU, garbage collection, connection resets, and header-size-related errors associated with SPDY traffic.

Typical attack path

1. Find an externally reachable service or gateway that uses a vulnerable Netty version and exposes SPDY decoding.
2. Confirm that SPDY negotiation or SPDY frame handling is accepted by the target service.
3. Open one or more network connections to the service.
4. Send crafted SPDY HEADERS frames with zlib-compressed header blocks that decompress beyond the configured maxHeaderSize.
5. Repeat the requests to keep Netty inflating oversized compressed header data after truncation is reached.
6. Cause elevated CPU usage, memory allocation churn, garbage collection pressure, event-loop stalls, request latency, and possible service outage.

How to detect it

To assess possible prior exploitation, correlate application logs, Netty logs, load balancer telemetry, JVM metrics, and network flow data around periods of CPU saturation, memory pressure, garbage collection spikes, connection resets, and service latency. Look for repeated SPDY requests or protocol negotiation followed by header parsing failures, oversized header warnings, frame truncation, decompression/inflate errors, or exceptions involving Netty SPDY classes. Network telemetry should be reviewed for clients sending unusually many SPDY HEADERS frames with small compressed payloads that trigger disproportionately high server CPU or request failures. JVM and container telemetry may show high allocation rates, long garbage collection pauses, event-loop backlog, thread starvation, or restarts without a corresponding increase in normal request volume. Because exploitation may not leave a unique artifact, detection should rely on correlation: suspicious SPDY traffic from one or more sources plus Netty header-size/truncation errors plus resource exhaustion in the affected service.

• io.netty.handler.codec.spdy.SpdyFrameCodec
• io.netty.handler.codec.spdy.SpdyHeaderBlockZlibDecoder
• io.netty.handler.codec.spdy.SpdyHeaderBlockRawDecoder
• maxHeaderSize
• SPDY HEADERS
• HEADERS frame
• header block
• truncated frame
• frame truncated
• TooLongFrameException
• Header size exceeded
• compressed header block
• zlib
• inflate
• java.lang.OutOfMemoryError: Java heap space
• java.lang.OutOfMemoryError: GC overhead limit exceeded
• java.lang.OutOfMemoryError: Direct buffer memory

What your security team should do

• Prioritize patching internet-facing, edge, gateway, proxy, API, and high-throughput services that use Netty and may accept SPDY traffic.
• Upgrade Netty to 4.1.136.Final, 4.2.16.Final, or vendor-fixed packages such as Red Hat RHSA-2026:47172, then redeploy all affected applications and containers.
• Inventory transitive and shaded Netty dependencies across Java applications because Netty is commonly embedded by frameworks and may not appear as a direct dependency.
• Disable SPDY support or block SPDY negotiation at ingress points if the protocol is not required.
• Add temporary rate limits and anomaly detection for repeated SPDY HEADERS frames, oversized decompressed headers, high connection churn, and CPU-bound event-loop behavior.
• Create operational alerts for sudden CPU saturation, garbage collection spikes, Netty event-loop delays, and increased request timeouts in services using affected Netty versions.
• Review logs and telemetry for signs of prior exploitation, focusing on repeated SPDY header parsing failures, maxHeaderSize violations, decompression-related errors, and correlated resource exhaustion.