<?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>Thu, 15 Oct 2026 09:47:48 +0000</lastBuildDate>
    <item>
      <title>CVE-2021-21290 — Local Information Disclosure Vulnerability in Netty on Unix-Like systems due temporary files</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2021-21290</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; netty&lt;/p&gt;
&lt;p&gt;Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp;amp; clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty&amp;#39;s multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method &amp;#34;File.createTempFile&amp;#34; on unix-like systems creates a random file, but, by default will create this file with the permissions &amp;#34;-rw-r--r--&amp;#34;. Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty&amp;#39;s &amp;#34;AbstractDiskHttpData&amp;#34; is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own &amp;#34;java.io.tmpdir&amp;#34; when you start the JVM or use &amp;#34;DefaultHttpDataFactory.setBaseDir(...)&amp;#34; to set the directory to something that is only readable by the current user.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; netty&lt;/p&gt;
&lt;p&gt;Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers &amp;amp; clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty&amp;#39;s multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method &amp;#34;File.createTempFile&amp;#34; on unix-like systems creates a random file, but, by default will create this file with the permissions &amp;#34;-rw-r--r--&amp;#34;. Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty&amp;#39;s &amp;#34;AbstractDiskHttpData&amp;#34; is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own &amp;#34;java.io.tmpdir&amp;#34; when you start the JVM or use &amp;#34;DefaultHttpDataFactory.setBaseDir(...)&amp;#34; to set the directory to something that is only readable by the current user.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2021-21290</guid>
    </item>
    <item>
      <title>USN-6049-1 — netty vulnerabilities</title>
      <link>https://cve.radiocsirt.org/vuln/usn-6049-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:16.04:LTS: netty, Ubuntu:Pro:18.04:LTS: netty, Ubuntu:Pro:20.04:LTS: netty, Ubuntu:22.04:LTS: netty&lt;/p&gt;
&lt;p&gt;It was discovered that Netty&amp;#39;s Zlib decoders did not limit memory
allocations. A remote attacker could possibly use this issue to cause
Netty to exhaust memory via malicious input, leading to a denial of
service. This issue only affected Ubuntu 16.04 ESM and Ubuntu 20.04 ESM.
(CVE-2020-11612)&lt;/p&gt;
&lt;p&gt;It was discovered that Netty created temporary files with excessive
permissions. A local attacker could possibly use this issue to expose
sensitive information. This issue only affected Ubuntu 16.04 ESM, Ubuntu
18.04 ESM, and Ubuntu 20.04 ESM. (CVE-2021-21290)&lt;/p&gt;
&lt;p&gt;It was discovered that Netty did not properly validate content-length
headers. A remote attacker could possibly use this issue to smuggle
requests. This issue was only fixed in Ubuntu 20.04 ESM. (CVE-2021-21295,
CVE-2021-21409)&lt;/p&gt;
&lt;p&gt;It was discovered that Netty&amp;#39;s Bzip2 decompression decoder did not limit
the decompressed output data size. A remote attacker could possibly use
this issue to cause Netty to exhaust memory via malicious input, leading
to a denial of service. This issue only affected Ubuntu 18.04 ESM, Ubuntu
20.04 ESM, Ubuntu 22.04 LTS, and Ubuntu 22.10. (CVE-2021-37136)&lt;/p&gt;
&lt;p&gt;It was discovered that Netty&amp;#39;s Snappy frame decoder function did not limit
chunk lengths. A remote attacker could possibly use this issue to cause
Netty to exhaust memory via malicious input, leading to a denial of
service. (CVE-2021-37137)&lt;/p&gt;
&lt;p&gt;It was discovered that Netty did not properly handle control chars at the
beginning and end of header names. A rem…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:16.04:LTS: netty, Ubuntu:Pro:18.04:LTS: netty, Ubuntu:Pro:20.04:LTS: netty, Ubuntu:22.04:LTS: netty&lt;/p&gt;
&lt;p&gt;It was discovered that Netty&amp;#39;s Zlib decoders did not limit memory
allocations. A remote attacker could possibly use this issue to cause
Netty to exhaust memory via malicious input, leading to a denial of
service. This issue only affected Ubuntu 16.04 ESM and Ubuntu 20.04 ESM.
(CVE-2020-11612)&lt;/p&gt;
&lt;p&gt;It was discovered that Netty created temporary files with excessive
permissions. A local attacker could possibly use this issue to expose
sensitive information. This issue only affected Ubuntu 16.04 ESM, Ubuntu
18.04 ESM, and Ubuntu 20.04 ESM. (CVE-2021-21290)&lt;/p&gt;
&lt;p&gt;It was discovered that Netty did not properly validate content-length
headers. A remote attacker could possibly use this issue to smuggle
requests. This issue was only fixed in Ubuntu 20.04 ESM. (CVE-2021-21295,
CVE-2021-21409)&lt;/p&gt;
&lt;p&gt;It was discovered that Netty&amp;#39;s Bzip2 decompression decoder did not limit
the decompressed output data size. A remote attacker could possibly use
this issue to cause Netty to exhaust memory via malicious input, leading
to a denial of service. This issue only affected Ubuntu 18.04 ESM, Ubuntu
20.04 ESM, Ubuntu 22.04 LTS, and Ubuntu 22.10. (CVE-2021-37136)&lt;/p&gt;
&lt;p&gt;It was discovered that Netty&amp;#39;s Snappy frame decoder function did not limit
chunk lengths. A remote attacker could possibly use this issue to cause
Netty to exhaust memory via malicious input, leading to a denial of
service. (CVE-2021-37137)&lt;/p&gt;
&lt;p&gt;It was discovered that Netty did not properly handle control chars at the
beginning and end of header names. A rem…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/usn-6049-1</guid>
    </item>
  </channel>
</rss>
