CVE-2026-56819

Netty is a network application framework for development of protocol servers and clients. In versions 4.2.0.Final through 4.2.15.Final and 4.1.0.Final through 4.1.135.Final, a remote unauthenticated peer can leak one direct ByteBuf per HTTP/2 DATA frame in applications that enable HTTP/2 content decompression via DelegatingDecompressorFrameListener. When a DATA frame is processed for a stream whose decompressor has already been closed, Http2Decompressor.decompress(...) calls decompressor.writeInbound(data.retain()) and does not release the retained buffer on the error path, eventually exhausting direct memory and crashing the JVM. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.

Summary

A remote, unauthenticated peer can leak one direct ByteBuf per HTTP/2 DATA frame in applications that enable HTTP/2 content decompression via DelegatingDecompressorFrameListener. When a DATA frame is processed for a stream whose decompressor has already been closed, Http2Decompressor.decompress(...) retains the frame buffer but never releases it on the error path, so its reference count never returns to zero. Repeating this over a long-lived HTTP/2 connection exhausts direct memory and crashes the JVM with OutOfMemoryError — a denial of service.

Details

In codec-http2/src/main/java/io/netty/handler/codec/http2/DelegatingDecompressorFrameListener.java, Http2Decompressor.decompress(...) does:

// around line 433
decompressor.writeInbound(data.retain());

The argument data.retain() is evaluated before writeInbound(...) executes, incrementing the buffer's reference count (refCnt: 1 -> 2). The very first statement of EmbeddedChannel.writeInbound(...) is ensureOpen() (EmbeddedChannel.java:360), which throws ClosedChannelException when the decompressor's internal EmbeddedChannel has already been closed.

When that happens:

• the DATA payload has been retain()ed but never entered the pipeline, so the decoder's finally { release() } never runs;
• the surrounding catch (Throwable t) block in decompress(...) (around line 451) does not release the extra reference;
• the input buffer therefore can never reach refCnt 0, and its (typically direct) memory is leaked.

The decompressor channel is closed on a reachable path: Http2Connection onStreamRemoved → Http2Decompressor.cleanup() → EmbeddedChannel.finishAndReleaseAll() (DelegatingDecompressorFrameListener.java:125-133 and 418-420).

A peer that sends DATA frames for a stream whose decompressor has already been cleaned up (e.g. continuing to send DATA after END_STREAM / stream removal) thus leaks one direct ByteBuf per frame.

Affected code: DelegatingDecompressorFrameListener.java, method Http2Decompressor.decompress(...) — the decompressor.writeInbound(data.retain()) call (line ~433) and its catch (Throwable t) block (line ~451), which lacks a data.release() rollback.

Suggested fix: track whether writeInbound succeeded and roll back the extra retain() only when the data never entered the pipeline:

boolean writeSucceeded = false;
try {
    decompressor.writeInbound(data.retain());
    writeSucceeded = true;            // pipeline now owns the release
    if (endOfStream) {
        decompressor.finish();
    }
    return 0;
} catch (Throwable t) {
    if (!writeSucceeded) {
        data.release();               // roll back the extra retain(); data never entered pipeline
    }
    if (t instanceof Http2Exception) {
        throw (Http2Exception) t;
    }
    throw streamError(stream.id(), INTERNAL_ERROR, t, ...);
}

| Case | writeSucceeded | catch action | Reason | |------|:---:|---|---| | ensureOpen() throws (this bug) | false | data.release() | data never entered pipeline | | handler throws internally | true | no release | decoder finally already released | | finish() throws | true | no release | writeInbound already succeeded |

PoC

Reproduced against the official, unmodified netty-codec-http2-4.2.15.Final.jar from Maven Central, using real netty classes and measuring ByteBuf.refCnt() directly (the leaking logic is not mocked).

Reproduction steps:

1. Download the official artifacts and their dependencies from Maven Central (version 4.2.15.Final): netty-common, netty-buffer, netty-transport, netty-resolver, netty-handler, netty-codec-base, netty-codec, netty-codec-http, netty-codec-http2, netty-codec-compression.
2. Build a real Http2Decompressor wrapping a real gzip decoder EmbeddedChannel (ZlibCodecFactory.newZlibDecoder(ZlibWrapper.GZIP)).
3. Close the internal…

A client might overload the server by issue frequent RST frames. This can cause a massive amount of load on the remote system and so cause a DDOS attack.

Impact

This is a DDOS attack, any http2 server is affected and so you should update as soon as possible.

Patches

This is patched in version 4.1.100.Final.

Workarounds

A user can limit the amount of RST frames that are accepted per connection over a timeframe manually using either an own Http2FrameListener implementation or an ChannelInboundHandler implementation (depending which http2 API is used).

References

• https://www.cve.org/CVERecord?id=CVE-2023-44487
• https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/
• https://cloud.google.com/blog/products/identity-security/google-cloud-mitigated-largest-ddos-attack-peaking-above-398-million-rps/

Red Hat Lightwell has released io.netty:netty-codec-http2 4.1.100.Final-rhlw-00001 with backported fixes for CVE-2025-55163, CVE-2026-33871, CVE-2026-42587, CVE-2026-47244, CVE-2026-48043, CVE-2026-50560, CVE-2026-56819, and CVE-2026-59900.

CVE-2025-55163: Netty MadeYouReset HTTP/2 DDoS Vulnerability

CVE-2026-33871: Netty HTTP/2 CONTINUATION Frame Flood DoS via Zero-Byte Frame Bypass

CVE-2026-42587: Netty: HttpContentDecompressor maxAllocation bypass via Content-Encoding: br/zstd/snappy enables decompression bomb DoS

CVE-2026-47244: Netty HTTP/2: Advertised MAX_CONCURRENT_STREAMS are not enforced

CVE-2026-48043: netty-codec-http2: ByteBuf Reference-Count Leak in DelegatingDecompressorFrameListener Leads to Memory Exhaustion

CVE-2026-50560: Netty susceptible to HTTP/2 Reset Attack with different on-the-wire signature

CVE-2026-56819: Netty: HTTP/2 decompression leaks ByteBuf reference count when the decompressor channel is already closed (Direct memory leak / OOM DoS)

CVE-2026-59900: Netty codec-http2: Lack of Host Header Deduplication in HTTP/2→HTTP/1.x Translation Leads to Request Routing Bypass

This patched artifact is a drop-in replacement for io.netty:netty-codec-http2 4.1.100.Final from Maven Central.

Root has patched GHSA-xpw8-rcwv-8f8p in the io.root.io.netty:netty-codec-http2 package for Root:Maven. Multiple fixed versions available.

Netty is a network application framework for development of protocol servers and clients. In versions 4.2.0.Final through 4.2.15.Final and 4.1.0.Final through 4.1.135.Final, a remote unauthenticated peer can leak one direct ByteBuf per HTTP/2 DATA frame in applications that enable HTTP/2 content decompression via DelegatingDecompressorFrameListener. When a DATA frame is processed for a stream whose decompressor has already been closed, Http2Decompressor.decompress(...) calls decompressor.writeInbound(data.retain()) and does not release the retained buffer on the error path, eventually exhausting direct memory and crashing the JVM. This issue is fixed in versions 4.1.136.Final and 4.2.16.Final.

TuxCare rebuilt 47 io.netty packages to address 23 CVEs. Fixed in 4.1.135.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 23 CVEs. Fixed in 4.1.130.Final-tuxcare.3.

TuxCare rebuilt 47 io.netty packages to address 59 CVEs. Fixed in 4.1.122.Final-tuxcare.2.

TuxCare rebuilt 47 io.netty packages to address 60 CVEs. Fixed in 4.1.119.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 41 CVEs. Fixed in 4.1.112.Final-tuxcare.6.

TuxCare rebuilt 47 io.netty packages to address 62 CVEs. Fixed in 4.1.111.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 48 CVEs. Fixed in 4.1.117.Final-tuxcare.3.

TuxCare rebuilt 47 io.netty packages to address 61 CVEs. Fixed in 4.1.108.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 61 CVEs. Fixed in 4.1.107.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 62 CVEs. Fixed in 4.1.94.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 14 CVEs. Fixed in 4.1.115.Final-tuxcare.8.

TuxCare rebuilt 46 io.netty packages to address 22 CVEs. Fixed in 4.1.79.Final-tuxcare.4.

TuxCare rebuilt 12 io.netty packages to address 19 CVEs. Fixed in 4.1.75.Final-tuxcare.5.

TuxCare rebuilt 8 io.netty packages to address 9 CVEs. Fixed in 4.1.93.Final-tuxcare.4.

TuxCare rebuilt 43 io.netty packages to address 7 CVEs. Fixed in 4.1.63.Final-tuxcare.8.

TuxCare rebuilt 11 io.netty packages to address 20 CVEs. Fixed in 4.1.73.Final-tuxcare.5.

TuxCare rebuilt 11 io.netty packages to address 18 CVEs. Fixed in 4.1.87.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 19 CVEs. Fixed in 4.1.99.Final-tuxcare.1.

TuxCare rebuilt 9 io.netty packages to address 10 CVEs. Fixed in 4.1.92.Final-tuxcare.6.

TuxCare rebuilt 6 io.netty packages to address 7 CVEs. Fixed in 4.1.82.Final-tuxcare.8.

TuxCare rebuilt 5 io.netty packages to address 9 CVEs. Fixed in 4.1.48.Final-tuxcare.4.

TuxCare rebuilt 46 io.netty packages to address 19 CVEs. Fixed in 4.1.80.Final-tuxcare.1.

TuxCare rebuilt 6 io.netty packages to address 13 CVEs. Fixed in 4.1.42.Final-tuxcare.1.

TuxCare rebuilt 7 io.netty packages to address 15 CVEs. Fixed in 4.1.101.Final-tuxcare.1.

TuxCare rebuilt 47 io.netty packages to address 19 CVEs. Fixed in 4.1.96.Final-tuxcare.1.

TuxCare rebuilt 7 io.netty packages to address 13 CVEs. Fixed in 4.1.100.Final-tuxcare.1.

TuxCare rebuilt 9 io.netty packages to address 13 CVEs. Fixed in 4.1.81.Final-tuxcare.1.

TuxCare rebuilt 15 io.netty packages to address 27 CVEs. Fixed in 4.1.72.Final-tuxcare.1.

TuxCare rebuilt 43 io.netty packages to address 25 CVEs. Fixed in 4.1.68.Final-tuxcare.1.

TuxCare rebuilt 40 io.netty packages to address 26 CVEs. Fixed in 4.1.53.Final-tuxcare.1.

TuxCare rebuilt 11 io.netty packages to address 21 CVEs. Fixed in 4.1.51.Final-tuxcare.1.

TuxCare rebuilt 7 io.netty packages to address 8 CVEs. Fixed in 4.1.52.Final-tuxcare.4.

TuxCare rebuilt 8 io.netty packages to address 11 CVEs. Fixed in 4.1.43.Final-tuxcare.3.

TuxCare rebuilt 10 io.netty packages to address 17 CVEs. Fixed in 4.1.49.Final-tuxcare.6.

TuxCare rebuilt 6 io.netty packages to address 11 CVEs. Fixed in 4.1.24.Final-tuxcare.2.

TuxCare rebuilt 36 io.netty packages to address 12 CVEs. Fixed in 4.1.29.Final-tuxcare.3.

TuxCare rebuilt 4 io.netty packages to address 10 CVEs. Fixed in 4.1.23.Final-tuxcare.2.

TuxCare rebuilt 43 io.netty packages to address 22 CVEs. Fixed in 4.1.60.Final-tuxcare.3.

TuxCare rebuilt 4 io.netty packages to address 8 CVEs. Fixed in 4.1.21.Final-tuxcare.3.

TuxCare rebuilt 7 io.netty packages to address 16 CVEs. Fixed in 4.1.38.Final-tuxcare.2.

TuxCare rebuilt 8 io.netty packages to address 16 CVEs. Fixed in 4.1.39.Final-tuxcare.2.

These are all security issues fixed in the netty-4.1.136-1.1 package on the GA media of openSUSE Tumbleweed.

Root has patched CVE-2026-56819 in the io.netty:netty-codec-http2 package for Root:Maven. Multiple fixed versions available.