<?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>Fri, 02 Oct 2026 17:06:02 +0000</lastBuildDate>
    <item>
      <title>certfr-2026-avi-1165 — De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquan…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-1165</link>
      <description>certfr-2026-avi-1165</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1165</guid>
    </item>
    <item>
      <title>CLEANSTART-2026-EO12643 — Security fix for CVE-2026-75596 applied in: elasticsearch 9.3.8-r5, solr 9.10.1-r8, solr 9.8.1-r3</title>
      <link>https://cve.radiocsirt.org/vuln/cleanstart-2026-eo12643</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: elasticsearch, CleanStart: solr&lt;/p&gt;
&lt;p&gt;CVE-2026-75596 affects multiple packages. This issue is resolved in later releases. See references for individual vulnerability details.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: elasticsearch, CleanStart: solr&lt;/p&gt;
&lt;p&gt;CVE-2026-75596 affects multiple packages. This issue is resolved in later releases. See references for individual vulnerability details.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cleanstart-2026-eo12643</guid>
    </item>
    <item>
      <title>EUVD-2026-357108</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-357108</link>
      <description>EUVD-2026-357108</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-357108</guid>
    </item>
    <item>
      <title>fkie_cve-2026-75596</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-75596</link>
      <description>&lt;p&gt;Netty is an asynchronous, event-driven network application framework. Prior to 4.1.137.Final and 4.2.17.Final, the default io.netty.handler.ssl.SniHandler constructors use the pre-handshake ClientHello aggregation path in handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java at io.netty.handler.ssl.SslClientHelloHandler#decode, where handshakeBuffer.clear() and writeBytes() recopy all previously received body bytes for every additional TLS record. An unauthenticated remote peer can advertise a large ClientHello and deliver its body in thousands of tiny records, causing quadratic CPU work on the event loop before the TLS handshake completes and degrading TLS handling for other clients. This issue is fixed in versions 4.1.137.Final and 4.2.17.Final.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Netty is an asynchronous, event-driven network application framework. Prior to 4.1.137.Final and 4.2.17.Final, the default io.netty.handler.ssl.SniHandler constructors use the pre-handshake ClientHello aggregation path in handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java at io.netty.handler.ssl.SslClientHelloHandler#decode, where handshakeBuffer.clear() and writeBytes() recopy all previously received body bytes for every additional TLS record. An unauthenticated remote peer can advertise a large ClientHello and deliver its body in thousands of tiny records, causing quadratic CPU work on the event loop before the TLS handshake completes and degrading TLS handling for other clients. This issue is fixed in versions 4.1.137.Final and 4.2.17.Final.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-75596</guid>
    </item>
    <item>
      <title>GHSA-fccg-mwvh-qqg4 — Netty: Fragmented ClientHello records trigger quadratic pre-handshake reassembly in default SNI parsing</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-fccg-mwvh-qqg4</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: io.netty:netty-handler&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Netty&amp;#39;s default SNI entrypoint reparses and recopies previously received ClientHello fragments on every additional TLS handshake record. A remote peer can send a small first record that advertises a large ClientHello length and then drip the body in many tiny records, causing **superlinear (quadratic) CPU work** before the handshake completes. With 4095 one-byte fragments, the handler recopies **8,386,560 bytes** from only **24,579 bytes** on the wire — a **341× amplification** ratio.&lt;/p&gt;
&lt;p&gt;### Affected Entrypoints&lt;/p&gt;
&lt;p&gt;- `io.netty.handler.ssl.SniHandler` — default constructors
- `io.netty.handler.ssl.SslClientHelloHandler` — pre-handshake ClientHello aggregation path&lt;/p&gt;
&lt;p&gt;### Vulnerable Code Locations&lt;/p&gt;
&lt;p&gt;- `handler/src/main/java/io/netty/handler/ssl/SniHandler.java:85`
- `handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:75` (decode entry)
- `handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:165` (handshakeBuffer.clear)
- `handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:174` (writeBytes re-copy)
- `codec-base/src/main/java/io/netty/handler/codec/ByteToMessageDecoder.java:294` (cumulation retention)&lt;/p&gt;
&lt;p&gt;### Exploit Path&lt;/p&gt;
&lt;p&gt;```
1. TCP connection → SniHandler → SslClientHelloHandler.decode
2. First record: TLS handshake header declaring large ClientHello length (e.g., 4096 bytes)
3. Attacker sends thousands of tiny follow-on handshake records (1 byte each)
4. On each fragment: handshakeBuffer.clear() + writeBytes() re-copi…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: io.netty:netty-handler&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Netty&amp;#39;s default SNI entrypoint reparses and recopies previously received ClientHello fragments on every additional TLS handshake record. A remote peer can send a small first record that advertises a large ClientHello length and then drip the body in many tiny records, causing **superlinear (quadratic) CPU work** before the handshake completes. With 4095 one-byte fragments, the handler recopies **8,386,560 bytes** from only **24,579 bytes** on the wire — a **341× amplification** ratio.&lt;/p&gt;
&lt;p&gt;### Affected Entrypoints&lt;/p&gt;
&lt;p&gt;- `io.netty.handler.ssl.SniHandler` — default constructors
- `io.netty.handler.ssl.SslClientHelloHandler` — pre-handshake ClientHello aggregation path&lt;/p&gt;
&lt;p&gt;### Vulnerable Code Locations&lt;/p&gt;
&lt;p&gt;- `handler/src/main/java/io/netty/handler/ssl/SniHandler.java:85`
- `handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:75` (decode entry)
- `handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:165` (handshakeBuffer.clear)
- `handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java:174` (writeBytes re-copy)
- `codec-base/src/main/java/io/netty/handler/codec/ByteToMessageDecoder.java:294` (cumulation retention)&lt;/p&gt;
&lt;p&gt;### Exploit Path&lt;/p&gt;
&lt;p&gt;```
1. TCP connection → SniHandler → SslClientHelloHandler.decode
2. First record: TLS handshake header declaring large ClientHello length (e.g., 4096 bytes)
3. Attacker sends thousands of tiny follow-on handshake records (1 byte each)
4. On each fragment: handshakeBuffer.clear() + writeBytes() re-copi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-fccg-mwvh-qqg4</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11882-1 — netty-4.1.138-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11882-1</link>
      <description>&lt;p&gt;netty-4.1.138-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;netty-4.1.138-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:11882-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-75596</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-75596</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 an asynchronous, event-driven network application framework. Prior to 4.1.137.Final and 4.2.17.Final, the default io.netty.handler.ssl.SniHandler constructors use the pre-handshake ClientHello aggregation path in handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java at io.netty.handler.ssl.SslClientHelloHandler#decode, where handshakeBuffer.clear() and writeBytes() recopy all previously received body bytes for every additional TLS record. An unauthenticated remote peer can advertise a large ClientHello and deliver its body in thousands of tiny records, causing quadratic CPU work on the event loop before the TLS handshake completes and degrading TLS handling for other clients. This issue is fixed in versions 4.1.137.Final and 4.2.17.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 an asynchronous, event-driven network application framework. Prior to 4.1.137.Final and 4.2.17.Final, the default io.netty.handler.ssl.SniHandler constructors use the pre-handshake ClientHello aggregation path in handler/src/main/java/io/netty/handler/ssl/SslClientHelloHandler.java at io.netty.handler.ssl.SslClientHelloHandler#decode, where handshakeBuffer.clear() and writeBytes() recopy all previously received body bytes for every additional TLS record. An unauthenticated remote peer can advertise a large ClientHello and deliver its body in thousands of tiny records, causing quadratic CPU work on the event loop before the TLS handshake completes and degrading TLS handling for other clients. This issue is fixed in versions 4.1.137.Final and 4.2.17.Final.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-75596</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2712 — Netty: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2712</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Netty ausnutzen, um Sicherheitsvorkehrungen zu umgehen, um einen Denial of Service Angriff durchzuführen, und um Informationen offenzulegen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Netty ausnutzen, um Sicherheitsvorkehrungen zu umgehen, um einen Denial of Service Angriff durchzuführen, und um Informationen offenzulegen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2712</guid>
    </item>
  </channel>
</rss>
