<?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>Sat, 03 Oct 2026 20:48:13 +0000</lastBuildDate>
    <item>
      <title>CLEANSTART-2026-ET24110 — Security fix for CVE-2026-56816 applied in: strimzi-kafka-operator 1.1.0-r2</title>
      <link>https://cve.radiocsirt.org/vuln/cleanstart-2026-et24110</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: strimzi-kafka-operator&lt;/p&gt;
&lt;p&gt;Security vulnerability affects the strimzi-kafka-operator package. This issue is resolved in later releases. See references for vulnerability details.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: strimzi-kafka-operator&lt;/p&gt;
&lt;p&gt;Security vulnerability affects the strimzi-kafka-operator package. This issue is resolved in later releases. See references for vulnerability details.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cleanstart-2026-et24110</guid>
    </item>
    <item>
      <title>EUVD-2026-339580</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-339580</link>
      <description>EUVD-2026-339580</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-339580</guid>
    </item>
    <item>
      <title>fkie_cve-2026-56816</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-56816</link>
      <description>&lt;p&gt;Netty is a network application framework for development of protocol servers and clients. Prior to 4.2.16.Final, Netty&amp;#39;s `Http3FrameCodec` buffers incoming data for HTTP/3 reserved frame types up to the wire-specified payload length without limits; `decodeFrame` trusts `payLoadLength`, allowing an attacker to open multiple QUIC streams and send reserved frames with very large payload lengths to cause memory exhaustion and denial of service. This issue is fixed in version 4.2.16.Final.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Netty is a network application framework for development of protocol servers and clients. Prior to 4.2.16.Final, Netty&amp;#39;s `Http3FrameCodec` buffers incoming data for HTTP/3 reserved frame types up to the wire-specified payload length without limits; `decodeFrame` trusts `payLoadLength`, allowing an attacker to open multiple QUIC streams and send reserved frames with very large payload lengths to cause memory exhaustion and denial of service. This issue is fixed in version 4.2.16.Final.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-56816</guid>
    </item>
    <item>
      <title>GHSA-hpcc-26xq-25fv — Netty: Memory Exhaustion via HTTP/3 Reserved Frame Types</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-hpcc-26xq-25fv</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: io.netty:netty-codec-http3&lt;/p&gt;
&lt;p&gt;### Summary
Netty&amp;#39;s Http3FrameCodec buffers incoming data for HTTP/3 reserved frame types up to the specified payload length without any limits. The payload length is read directly from the wire and trusted without validation. A bad actor can send a reserved frame with a payload length of up to Integer.MAX_VALUE, causing the server to buffer the data in memory. This leads to an OOM and a gradual Denial of Service due to memory exhaustion as multiple streams are opened.&lt;/p&gt;
&lt;p&gt;### Details
`io.netty.handler.codec.http3.Http3FrameCodec#decodeFrame` handles reserved frame types as follows:&lt;/p&gt;
&lt;p&gt;```java
                // Handling reserved frame types
                // https://tools.ietf.org/html/draft-ietf-quic-http-32#section-7.2.8
                if (in.readableBytes() &amp;lt; payLoadLength) {
                    return 0;
                }
```&lt;/p&gt;
&lt;p&gt;The `payLoadLength` is read directly from the wire and trusted implicitly. Since `payLoadLength` can be up to Integer.MAX_VALUE and there is no maximum payload length enforcement for reserved frames, the decoder will accumulate bytes in memory until the wire-provided length is reached.&lt;/p&gt;
&lt;p&gt;This allows a bad actor to exhaust server memory by opening multiple QUIC streams and sending reserved frames with large payload lengths, followed by a small amount of data (e.g., up to the defined limit) on each stream.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;```java
    @Test
    public void test() throws Exception {
        EventLoopGroup group = new MultiThreadIoEventLoopGroup(1, NioIoHandler.…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: io.netty:netty-codec-http3&lt;/p&gt;
&lt;p&gt;### Summary
Netty&amp;#39;s Http3FrameCodec buffers incoming data for HTTP/3 reserved frame types up to the specified payload length without any limits. The payload length is read directly from the wire and trusted without validation. A bad actor can send a reserved frame with a payload length of up to Integer.MAX_VALUE, causing the server to buffer the data in memory. This leads to an OOM and a gradual Denial of Service due to memory exhaustion as multiple streams are opened.&lt;/p&gt;
&lt;p&gt;### Details
`io.netty.handler.codec.http3.Http3FrameCodec#decodeFrame` handles reserved frame types as follows:&lt;/p&gt;
&lt;p&gt;```java
                // Handling reserved frame types
                // https://tools.ietf.org/html/draft-ietf-quic-http-32#section-7.2.8
                if (in.readableBytes() &amp;lt; payLoadLength) {
                    return 0;
                }
```&lt;/p&gt;
&lt;p&gt;The `payLoadLength` is read directly from the wire and trusted implicitly. Since `payLoadLength` can be up to Integer.MAX_VALUE and there is no maximum payload length enforcement for reserved frames, the decoder will accumulate bytes in memory until the wire-provided length is reached.&lt;/p&gt;
&lt;p&gt;This allows a bad actor to exhaust server memory by opening multiple QUIC streams and sending reserved frames with large payload lengths, followed by a small amount of data (e.g., up to the defined limit) on each stream.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;```java
    @Test
    public void test() throws Exception {
        EventLoopGroup group = new MultiThreadIoEventLoopGroup(1, NioIoHandler.…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-hpcc-26xq-25fv</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-56816</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-56816</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: netty, Ubuntu:Pro:16.04:LTS: netty, Ubuntu:Pro:18.04:LTS: netty, Ubuntu:Pro:20.04:LTS: netty, Ubuntu:Pro:22.04:LTS: netty, Ubuntu:Pro:24.04:LTS: netty, Ubuntu:Pro:26.04:LTS: netty&lt;/p&gt;
&lt;p&gt;Netty is a network application framework for development of protocol servers and clients. Prior to 4.2.16.Final, Netty&amp;#39;s `Http3FrameCodec` buffers incoming data for HTTP/3 reserved frame types up to the wire-specified payload length without limits; `decodeFrame` trusts `payLoadLength`, allowing an attacker to open multiple QUIC streams and send reserved frames with very large payload lengths to cause memory exhaustion and denial of service. This issue is fixed in version 4.2.16.Final.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:Pro:14.04:LTS: netty, Ubuntu:Pro:16.04:LTS: netty, Ubuntu:Pro:18.04:LTS: netty, Ubuntu:Pro:20.04:LTS: netty, Ubuntu:Pro:22.04:LTS: netty, Ubuntu:Pro:24.04:LTS: netty, Ubuntu:Pro:26.04:LTS: netty&lt;/p&gt;
&lt;p&gt;Netty is a network application framework for development of protocol servers and clients. Prior to 4.2.16.Final, Netty&amp;#39;s `Http3FrameCodec` buffers incoming data for HTTP/3 reserved frame types up to the wire-specified payload length without limits; `decodeFrame` trusts `payLoadLength`, allowing an attacker to open multiple QUIC streams and send reserved frames with very large payload lengths to cause memory exhaustion and denial of service. This issue is fixed in version 4.2.16.Final.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-56816</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2356 — Netty: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2356</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Netty ausnutzen, um Sicherheitsprüfungen zu umgehen, Anfragen oder Header zu manipulieren, Zertifikatsprüfungen zu unterlaufen sowie einen Denial of Service zu verursachen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Netty ausnutzen, um Sicherheitsprüfungen zu umgehen, Anfragen oder Header zu manipulieren, Zertifikatsprüfungen zu unterlaufen sowie einen Denial of Service zu verursachen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2356</guid>
    </item>
  </channel>
</rss>
