<?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 10:52:44 +0000</lastBuildDate>
    <item>
      <title>CVE-2021-21295 — Possible request smuggling in HTTP/2 due missing validation</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2021-21295</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; netty io.netty:netty-codec-http2&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 (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel&amp;#39;s pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround,…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; netty io.netty:netty-codec-http2&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 (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel&amp;#39;s pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround,…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2021-21295</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>
