CVE-2026-56745

What it actually does

The flaw is a remotely triggerable denial-of-service condition in Netty's SPDY-to-HTTP decoder. In affected Netty 4.1.x and 4.2.x versions, `SpdyHttpDecoder` allocates a pooled `ByteBuf` while handling a client-initiated `SYN_STREAM` frame with `FLAG_FIN=0` and tracks the partially built `FullHttpRequest` in `messageMap`. If the peer then resets the stream with `RST_STREAM`, or if accumulated content exceeds `maxContentLength`, the decoder removes the request state but fails to release the pooled buffer. Repeating this sequence leaks native/direct memory until the Java process exhausts Netty direct memory, causing request failures, channel instability, process crashes, or service unavailability. The issue requires no authentication, no user interaction, and can be exploited over the network where a vulnerable Netty SPDY codec is reachable.

Why it matters to the business

An attacker who can reach a service using the vulnerable Netty SPDY-to-HTTP codec can make the service run out of native memory and become unavailable. For internet-facing APIs, gateways, proxies, or application services, this can cause outages, degraded performance, failed customer transactions, failed health checks, container restarts, and cascading reliability issues in dependent systems. Although the CVSS impact is limited to availability and the EPSS score is currently low at 0.00612 with no known KEV listing or mature public exploitation, the vulnerability is unauthenticated, network-reachable, and only 21 days old, so exposed services should still be patched promptly, especially where Netty is embedded transitively in Java application stacks.

How an attack unfolds

An attacker first identifies a service endpoint that negotiates or accepts SPDY traffic handled by Netty's `SpdyHttpDecoder`. The attacker opens one or more network connections and sends client-initiated `SYN_STREAM` frames with `FLAG_FIN=0`, causing the decoder to allocate pooled direct memory for partially constructed HTTP request objects. Instead of completing the streams normally, the attacker then sends `RST_STREAM` frames for those streams, or sends enough content to exceed the configured `maxContentLength`. The vulnerable decoder removes the stream entry from its internal tracking map but does not release the associated pooled `ByteBuf`. By repeating this pattern across many streams or connections, the attacker gradually consumes Netty direct memory until allocations fail, channels close, requests time out, or the JVM/container restarts. No credentials or application-level privileges are required if the vulnerable protocol handler is reachable.

How to fix it

Upgrade Netty to a fixed version. For upstream Netty, use 4.1.136.Final or later for the 4.1 branch, or 4.2.16.Final or later for the 4.2 branch. For Red Hat-packaged Netty, apply the vendor fix for `codec-http` provided in RHSA-2026:47172. Because Netty is often pulled in transitively, update dependency lockfiles, shaded/relocated JARs, application server bundles, gateway components, and container images that include vulnerable Netty artifacts. If immediate upgrade is not possible, reduce exposure by disabling SPDY support where it is not required, blocking untrusted access to endpoints that accept SPDY traffic, enforcing strict connection and stream rate limits at a load balancer or reverse proxy, lowering connection lifetimes, and configuring memory/resource limits with safe restart behavior. Mitigations reduce exploitability but do not correct the buffer leak; patching remains the required fix.

How to confirm the fix worked

Confirm that no deployed application or container image includes vulnerable Netty versions 4.1.0.Final through 4.1.135.Final or 4.2.0.Final through 4.2.15.Final for affected codec components. Validate dependency resolution with build tools such as Maven, Gradle, SCA tooling, SBOM scanners, or vendor package inventory, and check runtime artifacts for embedded or shaded Netty JARs. Fixed upstream versions are 4.1.136.Final or later and 4.2.16.Final or later; Red Hat environments should verify the `codec-http` package level from RHSA-2026:47172. At runtime, confirm SPDY support is disabled if unused, or that patched code is loaded by the application. After remediation, perform controlled regression testing with incomplete/reset SPDY streams while monitoring direct memory, Netty allocator metrics, JVM native memory, error logs, and service availability to verify memory remains stable.

Typical attack path

1. Discover a network-exposed Java service, proxy, gateway, or application component using vulnerable Netty versions 4.1.0.Final through 4.1.135.Final or 4.2.0.Final through 4.2.15.Final with the SPDY-to-HTTP codec enabled.
2. Establish one or more connections capable of sending SPDY frames to the vulnerable endpoint.
3. Send client-initiated `SYN_STREAM` frames with `FLAG_FIN=0` so `SpdyHttpDecoder` allocates pooled `ByteBuf` memory for incomplete HTTP requests.
4. Abort the streams using `RST_STREAM`, or send content that exceeds `maxContentLength`, triggering cleanup logic that removes request state without releasing the pooled buffer.
5. Repeat the sequence to leak direct/native memory over time.
6. Cause Netty direct memory exhaustion, resulting in allocation failures, dropped connections, degraded service, process termination, or container restarts.

How to detect it

To determine whether exploitation may already have occurred, review application logs, JVM logs, container/orchestrator events, reverse proxy logs, network telemetry, and Netty leak detector output for signs of repeated incomplete SPDY streams followed by resets and increasing direct memory usage. Look for bursts of `SYN_STREAM` followed by `RST_STREAM`, repeated stream resets from the same sources, unexplained native/direct memory growth, `ByteBuf` leak warnings, allocator failures, `OutOfDirectMemoryError`, JVM crashes, container OOM kills, and service restarts. Netty's resource leak detector, if enabled, may log unreleased `ByteBuf` traces referencing `SpdyHttpDecoder`. Network detection is strongest where SPDY frame visibility exists in packet captures, protocol-aware proxies, or IDS sensors. Because exploitation causes resource exhaustion rather than code execution, there may be no persistent filesystem artifact; absence of logs does not prove absence of attempted exploitation if verbose Netty/JVM logging and protocol telemetry were not enabled.

• io.netty.handler.codec.spdy.SpdyHttpDecoder
• SYN_STREAM
• RST_STREAM
• FLAG_FIN=0
• LEAK: ByteBuf.release() was not called
• LEAK: ByteBuf was not released
• io.netty.util.ResourceLeakDetector
• io.netty.util.internal.OutOfDirectMemoryError
• failed to allocate direct memory
• Direct buffer memory
• OutOfMemoryError: Direct buffer memory
• maxContentLength
• FullHttpRequest
• messageMap
• PooledByteBufAllocator
• java.lang.OutOfMemoryError: Direct buffer memory
• Container killed due to OOM
• OOMKilled

What your security team should do

• Inventory all Java applications, gateways, proxies, and embedded products that include Netty, including transitive and shaded dependencies.
• Prioritize remediation for internet-facing or untrusted-network services that enable SPDY or include Netty's `codec-http`/SPDY codec path.
• Upgrade to Netty 4.1.136.Final or later, Netty 4.2.16.Final or later, or the Red Hat fixed `codec-http` package in RHSA-2026:47172.
• Disable SPDY support where it is not explicitly required, since SPDY is legacy protocol functionality and unnecessary exposure increases risk.
• Add temporary network controls, request/connection rate limits, and stream limits around exposed services until patches are deployed.
• Monitor for direct memory growth, Netty `ByteBuf` leak reports, `OutOfDirectMemoryError`, repeated connection resets, and abnormal restart patterns.
• Rebuild and redeploy container images and application bundles after dependency updates to avoid leaving vulnerable Netty JARs in packaged artifacts.
• Track vendor advisories for downstream products that bundle Netty, because remediation may require product-specific updates rather than only application dependency changes.