<?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-05T19:55:59.299078+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-2025-11965</id>
    <title>CVE-2025-11965</title>
    <updated>2026-10-05T19:55:59.655582+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Eclipse Foundation Vert.x</p>
<p>In Eclipse Vert.x versions [4.0.0, 4.5.21] and [5.0.0, 5.0.4], a StaticHandler configuration for restricting access to hidden files fails to restrict access to hidden directories, allowing unauthorized users to retrieve files within them (e.g. '.git/config').</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/cve-2025-11965"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-38f8-5428-x5cv</id>
    <title>GHSA-38f8-5428-x5cv — Netty vulnerable to HTTP Request Smuggling due to malformed Transfer-Encoding</title>
    <updated>2026-10-05T19:55:59.655657+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Maven: io.netty:netty-codec-http</p>
<p>### Summary
Netty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks.</p>
<p>### Details
Netty incorrectly marks a request as chunked when malformed "Transfer-Encoding: chunked, identity" is present.
According to RFC https://datatracker.ietf.org/doc/html/rfc9112#name-message-body-length</p>
<p>"
If a Transfer-Encoding header field is present in a request and the chunked transfer coding is not the final encoding,
 the message body length cannot be determined reliably; the server MUST respond with the 400 (Bad Request)
 status code and then close the connection.
"</p>
<p>A possible scenario is when Netty is behind a proxy that doesn't reject requests with "Transfer-Encoding: chunked, identity", but prefers "Content-Length" and forwards the content to Netty.</p>
<p>### PoC
The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a request body.</p>
<p>```java
@Test
    public void test() {
        String requestStr = "POST / HTTP/1.1\r\n" +
                "Host: localhost\r\n" +
                "Transfer-Encoding: chunked, identity\r\n" +
                "Content-Length: 48\r\n" +
                "\r\n" +
                "0\r\n" +
                "\r\n" +
                "GET /smuggled HTTP/1.1\r\n" +
                "Host: localhost\r\n" +
                "\r\n";</p>
<p>EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
        assertTrue(channel.writeInbound(Unpooled.copied…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-38f8-5428-x5cv"/>
  </entry>
</feed>
