<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 06 Oct 2026 13:04:16 +0000</lastBuildDate>
    <item>
      <title>CVE-2020-8908 — Temp directory permission issue in Guava</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2020-8908</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Google LLC Guava&lt;/p&gt;
&lt;p&gt;A temp directory creation vulnerability exists in all versions of Guava, allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava API com.google.common.io.Files.createTempDir(). By default, on unix-like systems, the created directory is world-readable (readable by an attacker with access to the system). The method in question has been marked @Deprecated in versions 30.0 and later and should not be used. For Android developers, we recommend choosing a temporary directory API provided by Android, such as context.getCacheDir(). For other Java developers, we recommend migrating to the Java 7 API java.nio.file.Files.createTempDirectory() which explicitly configures permissions of 700, or configuring the Java runtime&amp;#39;s java.io.tmpdir system property to point to a location whose permissions are appropriately configured.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Google LLC Guava&lt;/p&gt;
&lt;p&gt;A temp directory creation vulnerability exists in all versions of Guava, allowing an attacker with access to the machine to potentially access data in a temporary directory created by the Guava API com.google.common.io.Files.createTempDir(). By default, on unix-like systems, the created directory is world-readable (readable by an attacker with access to the system). The method in question has been marked @Deprecated in versions 30.0 and later and should not be used. For Android developers, we recommend choosing a temporary directory API provided by Android, such as context.getCacheDir(). For other Java developers, we recommend migrating to the Java 7 API java.nio.file.Files.createTempDirectory() which explicitly configures permissions of 700, or configuring the Java runtime&amp;#39;s java.io.tmpdir system property to point to a location whose permissions are appropriately configured.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2020-8908</guid>
    </item>
    <item>
      <title>GHSA-38f8-5428-x5cv — Netty vulnerable to HTTP Request Smuggling due to malformed Transfer-Encoding</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-38f8-5428-x5cv</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: io.netty:netty-codec-http&lt;/p&gt;
&lt;p&gt;### Summary
Netty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks.&lt;/p&gt;
&lt;p&gt;### Details
Netty incorrectly marks a request as chunked when malformed &amp;#34;Transfer-Encoding: chunked, identity&amp;#34; is present.
According to RFC https://datatracker.ietf.org/doc/html/rfc9112#name-message-body-length&lt;/p&gt;
&lt;p&gt;&amp;#34;
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.
&amp;#34;&lt;/p&gt;
&lt;p&gt;A possible scenario is when Netty is behind a proxy that doesn&amp;#39;t reject requests with &amp;#34;Transfer-Encoding: chunked, identity&amp;#34;, but prefers &amp;#34;Content-Length&amp;#34; and forwards the content to Netty.&lt;/p&gt;
&lt;p&gt;### PoC
The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a request body.&lt;/p&gt;
&lt;p&gt;```java
@Test
    public void test() {
        String requestStr = &amp;#34;POST / HTTP/1.1\r\n&amp;#34; +
                &amp;#34;Host: localhost\r\n&amp;#34; +
                &amp;#34;Transfer-Encoding: chunked, identity\r\n&amp;#34; +
                &amp;#34;Content-Length: 48\r\n&amp;#34; +
                &amp;#34;\r\n&amp;#34; +
                &amp;#34;0\r\n&amp;#34; +
                &amp;#34;\r\n&amp;#34; +
                &amp;#34;GET /smuggled HTTP/1.1\r\n&amp;#34; +
                &amp;#34;Host: localhost\r\n&amp;#34; +
                &amp;#34;\r\n&amp;#34;;&lt;/p&gt;
&lt;p&gt;EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
        assertTrue(channel.writeInbound(Unpooled.copied…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: io.netty:netty-codec-http&lt;/p&gt;
&lt;p&gt;### Summary
Netty incorrectly parses malformed Transfer-Encoding, enabling request smuggling attacks.&lt;/p&gt;
&lt;p&gt;### Details
Netty incorrectly marks a request as chunked when malformed &amp;#34;Transfer-Encoding: chunked, identity&amp;#34; is present.
According to RFC https://datatracker.ietf.org/doc/html/rfc9112#name-message-body-length&lt;/p&gt;
&lt;p&gt;&amp;#34;
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.
&amp;#34;&lt;/p&gt;
&lt;p&gt;A possible scenario is when Netty is behind a proxy that doesn&amp;#39;t reject requests with &amp;#34;Transfer-Encoding: chunked, identity&amp;#34;, but prefers &amp;#34;Content-Length&amp;#34; and forwards the content to Netty.&lt;/p&gt;
&lt;p&gt;### PoC
The test below shows Netty successfully parsing the second request, demonstrating how an attacker can smuggle a second request inside a request body.&lt;/p&gt;
&lt;p&gt;```java
@Test
    public void test() {
        String requestStr = &amp;#34;POST / HTTP/1.1\r\n&amp;#34; +
                &amp;#34;Host: localhost\r\n&amp;#34; +
                &amp;#34;Transfer-Encoding: chunked, identity\r\n&amp;#34; +
                &amp;#34;Content-Length: 48\r\n&amp;#34; +
                &amp;#34;\r\n&amp;#34; +
                &amp;#34;0\r\n&amp;#34; +
                &amp;#34;\r\n&amp;#34; +
                &amp;#34;GET /smuggled HTTP/1.1\r\n&amp;#34; +
                &amp;#34;Host: localhost\r\n&amp;#34; +
                &amp;#34;\r\n&amp;#34;;&lt;/p&gt;
&lt;p&gt;EmbeddedChannel channel = new EmbeddedChannel(new HttpRequestDecoder());
        assertTrue(channel.writeInbound(Unpooled.copied…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-38f8-5428-x5cv</guid>
    </item>
  </channel>
</rss>
