<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-28T07:45:12.672484+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-42583</id>
    <title>CVE-2026-42583 — Netty: Lz4FrameDecoder resource exhaustion</title>
    <updated>2026-09-28T07:45:12.674458+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> netty, io.netty netty-codec, io.netty netty-codec-compression</p>
<p>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.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-42583"/>
  </entry>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/ghsa-mj4r-2hfc-f8p6</id>
    <title>GHSA-mj4r-2hfc-f8p6 — Netty Lz4FrameDecoder is vulnerable to resource exhaustion</title>
    <updated>2026-09-28T07:45:12.674618+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Maven: io.netty:netty-codec-compression, Maven: io.netty:netty-codec</p>
<p>### 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.</p>
<p>### Details
io.netty.handler.codec.compression.Lz4FrameDecoder#decode
Header fields are trusted for sizing. On the compressed path, after `readableBytes &gt;= compressedLength`, the decoder does `ctx.alloc().buffer(decompressedLength, decompressedLength)` then decompresses.</p>
<p>### PoC
The test below demonstrates how an attacker sending 22 bytes will force the server to allocate 32MB</p>
<p>```java
    @Test
    void test() throws Exception {
        EventLoopGroup workerGroup = new MultiThreadIoEventLoopGroup(NioIoHandler.newFactory());
        try {
            AtomicReference&lt;Throwable&gt; serverError = new AtomicReference&lt;&gt;();
            CountDownLatch latch = new CountDownLatch(1);</p>
<p>ServerBootstrap server = new ServerBootstrap()
                    .group(workerGroup)
                    .channel(NioServerSocketChannel.class)
                    .childHandler(new ChannelInitializer&lt;SocketChannel&gt;() {
                        @Override
                        protected void initChannel(SocketChannel ch) {
                            ch.pipeline()
                                    .addLast(new Lz4FrameDecoder())
                                    .addLast(new ChannelInboundHandlerAdapter() {…</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/ghsa-mj4r-2hfc-f8p6"/>
  </entry>
</feed>
