CVE-2026-55831

What it actually does

The flaw is a remotely triggerable denial-of-service condition in Netty's SPDY/3.1 SETTINGS frame decoder. Before Netty 4.1.136.Final and 4.2.16.Final, a peer can declare a very large number of SETTINGS entries within the 24-bit SPDY frame length limit. Netty then materializes each unique setting ID into DefaultSpdySettingsFrame, causing a small amount of network input, roughly a 2 MiB frame, to expand into substantial heap allocation and ordered-map insertion work. Because exploitation requires only network access to a service that accepts SPDY/3.1 traffic and does not require authentication or user interaction, vulnerable services can suffer excessive memory consumption, garbage-collection pressure, worker-thread exhaustion, degraded latency, or process termination.

Why it matters to the business

An unauthenticated remote attacker can crash or severely slow services that expose vulnerable Netty-based SPDY/3.1 endpoints, causing customer-facing outages, failed transactions, degraded API availability, and increased operational load from restarts or autoscaling churn. Although this is not known to be in CISA KEV and is not associated with ransomware activity, exploit code is reported available, so internet-facing or high-volume Netty services should be prioritized. The impact may be broader than a single application because Netty is commonly embedded as a transitive dependency in Java network services and platform components.

How an attack unfolds

An attacker first identifies a service that uses a vulnerable Netty version and accepts SPDY/3.1 traffic. The attacker establishes a TCP/TLS session as appropriate for the exposed protocol and sends a syntactically valid SPDY SETTINGS frame with a peer-declared entry count near the maximum allowed by the 24-bit frame length. The frame is relatively small on the wire, but it contains many unique setting identifiers. Vulnerable Netty decodes the frame and inserts each unique setting into DefaultSpdySettingsFrame, consuming heap and CPU for map storage and ordered insertion. Repeated requests or concurrent connections can amplify the effect, leading to heavy garbage collection, event-loop stalls, OutOfMemoryError conditions, connection drops, or application restarts. Threat activity is not currently attributed to a named group, but exploit availability lowers the barrier for commodity denial-of-service attempts.

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 fixed codec-http package provided by RHSA-2026:47172. Because Netty is often included transitively, update dependency lockfiles, application server bundles, shaded JARs, container images, and vendor components that embed Netty. If immediate patching is not possible, disable SPDY/3.1 support where feasible, restrict exposure of affected services to trusted networks, enforce strict connection and request-rate limits, cap frame sizes or protocol-specific SETTINGS counts at a proxy or gateway if supported, and configure memory limits and restart policies to reduce blast radius. Mitigations should be treated as temporary because the vulnerable decoder behavior remains present until the dependency is updated.

How to confirm the fix worked

Confirm that all runtime artifacts resolve to Netty 4.1.136.Final or later, Netty 4.2.16.Final or later, or the Red Hat fixed codec-http package from RHSA-2026:47172. Validate both build-time and runtime dependency trees because vulnerable Netty JARs may be shaded or bundled. For Java applications, inspect dependency manifests, SBOMs, container layers, and classpath contents for netty-codec-http, netty-codec, and related io.netty artifacts. Verify that SPDY/3.1 is disabled if it is not required. In staging, use safe protocol testing to confirm oversized or high-count SPDY SETTINGS frames are rejected or handled without abnormal heap growth, prolonged garbage collection, or event-loop stalls. Monitor after deployment for reduced OutOfMemoryError frequency, stable heap usage, and absence of repeated malformed or oversized SPDY SETTINGS traffic.

Typical attack path

1. Discover an externally reachable service that negotiates or accepts SPDY/3.1 and is built on a vulnerable Netty release.
2. Open one or more network connections to the service without authenticating.
3. Send a valid SPDY/3.1 SETTINGS frame with an unusually large number of unique SETTINGS IDs, approaching the frame-length limit.
4. Cause Netty to allocate and insert hundreds of thousands of settings entries into DefaultSpdySettingsFrame.
5. Repeat the payload across connections or over time to increase heap pressure and CPU usage.
6. Trigger degraded performance, garbage-collection storms, worker/event-loop starvation, OutOfMemoryError, service crash, or automated restarts.

How to detect it

Review network, application, JVM, and infrastructure telemetry for evidence of attempted or successful denial of service. Useful log sources include load balancer and reverse-proxy logs, packet captures or network IDS logs, Java application logs, JVM garbage-collection logs, container runtime events, orchestrator restart events, APM traces, and host metrics. Look for bursts of SPDY/3.1 traffic containing unusually large SETTINGS frames, many short-lived connections from the same source, connection resets followed by heap growth, long garbage-collection pauses, Netty event-loop stalls, and OutOfMemoryError events. Successful exploitation may leave no application-level authentication trail because the attack occurs during protocol processing. Correlate spikes in inbound traffic to SPDY-capable endpoints with memory exhaustion, pod or process restarts, elevated CPU from garbage collection, degraded latency, or 5xx responses. If packet data is available, inspect for SPDY SETTINGS frames with exceptionally high entry counts or near-maximum frame lengths. Where threat intelligence tooling supports it, add detections for exploit attempts targeting Netty SPDY SETTINGS handling; no named threat actor is currently provided for this vulnerability.

• io.netty.handler.codec.spdy.DefaultSpdySettingsFrame
• io.netty.handler.codec.spdy.SpdySettingsFrame
• io.netty.handler.codec.spdy.SpdyFrameDecoder
• OutOfMemoryError: Java heap space
• java.lang.OutOfMemoryError
• GC overhead limit exceeded
• SPDY/3.1
• SETTINGS frame
• spdy SETTINGS
• RHSA-2026:47172
• netty-codec-http
• netty-all-4.1.
• netty-all-4.2.
• netty-codec-http-4.1.
• netty-codec-http-4.2.

What your security team should do

• Inventory internet-facing and internal Java services that use Netty, especially services exposing HTTP/2-era legacy protocol negotiation or SPDY/3.1 support.
• Prioritize upgrades for externally reachable services because the issue is network-exploitable, unauthenticated, low-complexity, and has reported exploit availability.
• Upgrade to Netty 4.1.136.Final or 4.2.16.Final or later, or apply the Red Hat fixed codec-http package from RHSA-2026:47172 where applicable.
• Search dependency trees, SBOMs, container images, and shaded JARs for embedded vulnerable Netty versions rather than relying only on top-level package names.
• Disable SPDY/3.1 support unless there is a confirmed business requirement.
• Add detection for abnormal SPDY SETTINGS traffic, repeated connection resets, JVM OutOfMemoryError events, garbage-collection storms, and Netty event-loop stalls.
• Review historical telemetry from the publication date onward for signs of unexplained memory exhaustion or availability incidents affecting Netty-based services.
• Apply temporary network rate limits, connection limits, and service isolation for systems that cannot be patched immediately.