CVE-2026-33871

Netty is an asynchronous, event-driven network application framework. In versions prior to 4.1.132.Final and 4.2.10.Final, a remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of CONTINUATION frames. The server's lack of a limit on the number of CONTINUATION frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive. Versions 4.1.132.Final and 4.2.10.Final fix the issue.

Summary

A remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of CONTINUATION frames. The server's lack of a limit on the number of CONTINUATION frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive.

Details

The vulnerability exists in Netty's DefaultHttp2FrameReader. When an HTTP/2 HEADERS frame is received without the END_HEADERS flag, the server expects one or more subsequent CONTINUATION frames. However, the implementation does not enforce a limit on the count of these CONTINUATION frames.

The key issue is located in codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java. The verifyContinuationFrame() method checks for stream association but fails to implement a frame count limit.

Any user can exploit this by sending a stream of CONTINUATION frames with a zero-byte payload. While Netty has a maxHeaderListSize protection to limit the total size of headers, this check is never triggered by zero-byte frames. The logic effectively evaluates to maxHeaderListSize - 0 < currentSize, which will not trigger the limit until a non-zero byte is added. As a result, the server is forced to process an unlimited number of frames, consuming a CPU thread and monopolizing the connection.

codec-http2/src/main/java/io/netty/handler/codec/http2/DefaultHttp2FrameReader.java

verifyContinuationFrame() (lines 381-393) — No frame count check:

private void verifyContinuationFrame() throws Http2Exception {
    verifyAssociatedWithAStream();
    if (headersContinuation == null) {
        throw connectionError(PROTOCOL_ERROR, "...");
    }
    if (streamId != headersContinuation.getStreamId()) {
        throw connectionError(PROTOCOL_ERROR, "...");
    }
    // NO frame count limit!
}

HeadersBlockBuilder.addFragment() (lines 695-723) — Byte limit bypassed by 0-byte frames:

// Line 710-711: This check NEVER fires when len=0
if (headersDecoder.configuration().maxHeaderListSizeGoAway() - len <
        headerBlock.readableBytes()) {
    headerSizeExceeded();  // 10240 - 0 < 1 => FALSE always
}

When len=0: maxGoAway - 0 < readableBytes → 10240 < 1 → FALSE. The byte limit is never triggered.

Impact

This is a CPU-based Denial of Service (DoS). Any service using Netty's default HTTP/2 server implementation is impacted. An unauthenticated user can exhaust server CPU resources and block legitimate users, leading to service unavailability. The low bandwidth requirement for the attack makes it highly practical.

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 CVE-2026-33871 in the io.netty:netty-codec-http2 package for Root:Maven. Multiple fixed versions available.

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 an asynchronous, event-driven network application framework. In versions prior to 4.1.132.Final and 4.2.10.Final, a remote user can trigger a Denial of Service (DoS) against a Netty HTTP/2 server by sending a flood of CONTINUATION frames. The server's lack of a limit on the number of CONTINUATION frames, combined with a bypass of existing size-based mitigations using zero-byte frames, allows an user to cause excessive CPU consumption with minimal bandwidth, rendering the server unresponsive. Versions 4.1.132.Final and 4.2.10.Final fix the issue.

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

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

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

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

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

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 62 CVEs. Fixed in 4.1.111.Final-tuxcare.1.

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 12 io.netty packages to address 28 CVEs. Fixed in 4.1.79.Final-tuxcare.2.

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

TuxCare rebuilt 3 io.netty packages to address 3 CVEs. Fixed in 4.1.87.Final-tuxcare.2.

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

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

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

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

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

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

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

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

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

This update for netty, netty-tcnative fixes the following issues:

Upidate to 4.1.132:

• CVE-2026-33870: incorrectly parses quoted strings in HTTP/1.1 can lead to request smuggling (bsc#1261031).
• CVE-2026-33871: sending a flood of CONTINUATION frames can lead to a denial of service (bsc#1261043).

Changelog:

• Upgrade to upstream version 4.1.132

• Fixes:

• Fix Incorrect nanos-to-millis conversion in epoll_wait EINTR retry loop
• Make RefCntOpenSslContext.deallocate more robust
• HTTP2: Correctly account for padding when decompress
• Fix high-order bit aliasing in HttpUtil.validateToken
• fix: the precedence of + is higher than >>
• AdaptiveByteBufAllocator: make sure byteBuf.capacity() not greater than byteBuf.maxCapacity()
• AdaptivePoolingAllocator: call unreserveMatchingBuddy(...) if byteBuf initialization failed
• Don't assume CertificateFactory is thread-safe
• Fix HttpObjectAggregator leaving connection stuck after 413 with AUTO_READ=false
• HTTP2: Ensure preface is flushed in all cases
• Fix UnsupportedOperationException in readTrailingHeaders
• Fix client_max_window_bits parameter handling in permessage-deflate extension
• Native transports: Fix possible fd leak when fcntl fails.
• Kqueue: Fix undefined behaviour when GetStringUTFChars fails and SO_ACCEPTFILTER is supported
• Kqueue: Possible overflow when using netty_kqueue_bsdsocket_setAcceptFilter(...)
• Native transports: Fix undefined behaviour when GetStringUTFChars fails while open FD
• Epoll: Add null checks for safety reasons
• Epoll: Use correct value to initialize mmsghdr.msg_namelen
• Epoll: Fix support for IP_RECVORIGDSTADDR
• AdaptivePoolingAllocator: remove ensureAccessible() call in capacity(int) method
• Epoll: setTcpMg5Sig(...) might overflow
• JdkZlibDecoder: accumulate decompressed output before firing channelRead
• Limit the number of Continuation frames per HTTP2 Headers (bsc#1261043, CVE-2026-33871)
• Stricter HTTP/1.1 chunk extension parsing (bsc#1261031, CVE-2026-33870)
• rediff

• Upgrade to upstream version 4.1.131

• NioDatagramChannel.block(...) does not early return on failure
• Support for AWS Libcrypto (AWS-LC) netty-tcnative build
• codec-dns: Decompress MX RDATA exchange domain names during DNS record decoding
• Buddy allocation for large buffers in adaptive allocator
• SslHandler: Only resume on EventLoop if EventLoop is not shutting down already
• Wrap ECONNREFUSED in PortUnreachableException for UDP
• Bump com.ning:compress-lzf (4.1)
• Fix adaptive allocator bug from not noticing failed allocation
• Avoid loosing original read exception
• Backport multiple adaptive allocator changes

• Upgrade to version 4.1.130
• Upgrade to version 2.0.75 Final

• No formal changelog present
• Needed by netty >= 4.2.11