CVE-2026-48043

What it actually does

The flaw is a remote, unauthenticated denial-of-service condition in Netty's HTTP/2 decompression handling. In affected versions of netty-codec-http2 before 4.1.135.Final and 4.2.15.Final, the DelegatingDecompressorFrameListener uses per-stream EmbeddedChannel instances to decompress gzip, deflate, or zstd HTTP/2 payloads. Under certain frame and flow-control error conditions, decompressed pooled ByteBuf objects are not released correctly. Repeated triggering can leak direct or heap buffer memory until the Java process encounters an OutOfMemoryError, potentially terminating the JVM or making the service unresponsive.

Why it matters to the business

Services built on affected Netty HTTP/2 components may be remotely crashed or degraded by crafted traffic without authentication. The most likely consequence is service instability, increased memory usage, JVM restarts, failed requests, and temporary outage of APIs, gateways, microservices, or application servers that accept HTTP/2 traffic with compressed request bodies. The issue is not known to be in the CISA KEV catalog, is not associated with ransomware use, and currently has low EPSS and no public exploit maturity indicated, but exposure is still important because exploitation is network-reachable and can affect widely deployed Java infrastructure components.

How an attack unfolds

An attacker identifies an application endpoint that uses an affected Netty HTTP/2 stack and accepts compressed HTTP/2 data. The attacker opens HTTP/2 connections and sends crafted sequences of compressed DATA frames using supported encodings such as gzip, deflate, or zstd. The frames are arranged so decompression produces pooled ByteBuf chunks while the HTTP/2 flow controller throws an exception or terminates processing before ownership is released correctly. Each successful trigger leaks memory. By repeating this across streams or connections, the attacker causes memory pressure to accumulate until the JVM slows, fails requests, triggers garbage collection storms, throws OutOfMemoryError, or exits. No authentication or user interaction is required; impact depends on whether the vulnerable Netty HTTP/2 decompression path is reachable.

How to fix it

Upgrade Netty to a patched release. For the 4.1.x line, upgrade netty-codec-http2 and related Netty modules to 4.1.135.Final or later. For the 4.2.x line, upgrade to 4.2.15.Final or later. Ensure all Netty artifacts in the dependency graph are aligned to the same patched version to avoid mixed-version runtime behavior. If immediate upgrade is not possible, reduce exposure by disabling HTTP/2 where feasible, disabling request-body compression/decompression for HTTP/2, rejecting unsupported or unnecessary content encodings, enforcing strict request size and stream concurrency limits, applying connection and rate limits at proxies/load balancers, and ensuring JVM/container memory limits and restart policies are configured to fail safely. These mitigations reduce exploitability but do not replace upgrading.

How to confirm the fix worked

Confirm the deployed application resolves netty-codec-http2 to 4.1.135.Final or later on the 4.1 branch, or 4.2.15.Final or later on the 4.2 branch. Use dependency inspection tools such as Maven dependency:tree, Gradle dependencies/dependencyInsight, SBOM scans, container image scans, or runtime classpath inspection to verify that no older netty-codec-http2 JAR remains packaged. Validate that transitive dependencies from frameworks, gateways, RPC libraries, or application servers do not override the patched version. After deployment, perform controlled HTTP/2 compressed request testing while monitoring direct memory, heap usage, Netty leak detection output, garbage collection activity, process restarts, and application error logs. Exposure is reduced if HTTP/2 decompression is disabled or unavailable, but the durable validation is confirming patched Netty artifacts are in use.

Typical attack path

1. Discover a public or internal service that supports HTTP/2 and is implemented with an affected Netty version.
2. Confirm the service accepts compressed HTTP/2 payloads using gzip, deflate, or zstd.
3. Open one or more HTTP/2 connections and create streams carrying crafted compressed DATA frames.
4. Trigger HTTP/2 flow-control or decompression processing errors that cause pooled ByteBuf objects to remain unreleased.
5. Repeat the request pattern to accumulate unreleased memory in the JVM.
6. Cause service degradation, request failures, excessive garbage collection, OutOfMemoryError, JVM crash, or container restart.

How to detect it

To determine whether exploitation may have already occurred, review application logs, JVM stderr/stdout, container runtime events, orchestration events, reverse proxy logs, and APM metrics around periods of memory growth or unexpected service restarts. Look for OutOfMemoryError events, direct buffer memory exhaustion, Netty ByteBuf leak detector messages, HTTP/2 flow-control exceptions, decompression-related stack traces, increased compressed HTTP/2 DATA frames, abnormal stream resets, and bursts of short-lived HTTP/2 connections from the same source. Correlate these events with request metadata such as HTTP/2 protocol use, Content-Encoding values of gzip, deflate, or zstd, elevated 5xx responses, container OOMKilled events, and JVM restarts. Because this vulnerability causes availability impact rather than code execution, forensic evidence is most likely to appear as memory-leak symptoms and protocol-processing errors rather than persistent files or malware artifacts.

• java.lang.OutOfMemoryError
• OutOfMemoryError: Direct buffer memory
• OutOfMemoryError: Java heap space
• io.netty.util.ResourceLeakDetector
• LEAK: ByteBuf.release() was not called
• io.netty.handler.codec.http2.DelegatingDecompressorFrameListener
• io.netty.handler.codec.http2.Http2Exception
• io.netty.handler.codec.http2.Http2Exception$StreamException
• io.netty.handler.codec.http2.Http2FlowController
• io.netty.handler.codec.compression.ZlibDecoder
• io.netty.handler.codec.compression.ZstdDecoder
• Content-Encoding: gzip
• Content-Encoding: deflate
• Content-Encoding: zstd
• HTTP/2 stream error
• FLOW_CONTROL_ERROR
• RST_STREAM
• GOAWAY
• OOMKilled
• Killed process java

What your security team should do

• Inventory applications, containers, API gateways, and Java services that include netty-codec-http2 and expose HTTP/2 endpoints.
• Prioritize internet-facing or high-traffic services that accept compressed HTTP/2 request bodies, even though the CVE is not in KEV and EPSS is currently low.
• Upgrade Netty to 4.1.135.Final or later, or 4.2.15.Final or later, and keep all Netty modules version-aligned.
• If upgrade cannot be completed quickly, temporarily disable HTTP/2 or HTTP/2 decompression where operationally acceptable.
• Apply rate limits, HTTP/2 stream concurrency limits, request body size limits, and connection limits at edge proxies and service meshes.
• Monitor JVM heap/direct memory, garbage collection, container OOM kills, Netty leak detector logs, and spikes in HTTP/2 protocol exceptions.
• Search historical logs for OutOfMemoryError, ByteBuf leak warnings, HTTP/2 flow-control exceptions, and abnormal compressed HTTP/2 traffic patterns.
• Add SBOM or dependency-policy checks to prevent reintroduction of vulnerable Netty versions through transitive dependencies.