<?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 19:40:29 +0000</lastBuildDate>
    <item>
      <title>certfr-2026-avi-1256 — 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-1256</link>
      <description>certfr-2026-avi-1256</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-1256</guid>
    </item>
    <item>
      <title>Withdrawn: CLEANSTART-2026-AM39668 — yawkat LZ4 Java provides LZ4 compression for Java</title>
      <link>https://cve.radiocsirt.org/vuln/cleanstart-2026-am39668</link>
      <description>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: apache-nifi&lt;/p&gt;
&lt;p&gt;Multiple security vulnerabilities affect the apache-nifi package. yawkat LZ4 Java provides LZ4 compression for Java. See references for individual vulnerability details.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Withdrawn by the publisher.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; CleanStart: apache-nifi&lt;/p&gt;
&lt;p&gt;Multiple security vulnerabilities affect the apache-nifi package. yawkat LZ4 Java provides LZ4 compression for Java. See references for individual vulnerability details.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cleanstart-2026-am39668</guid>
    </item>
    <item>
      <title>EUVD-2026-355102</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-355102</link>
      <description>EUVD-2026-355102</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-355102</guid>
    </item>
    <item>
      <title>fkie_cve-2026-59949</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-59949</link>
      <description>&lt;p&gt;yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-59949</guid>
    </item>
    <item>
      <title>GHSA-xx22-p4ch-683r — LZ4 Java: Native XXHash implementations can crash the JVM when passed invalid byte array ranges</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-xx22-p4ch-683r</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: at.yawk.lz4:lz4-java, Maven: org.lz4:lz4-java&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Insufficient validation of byte array arguments in JNI-based XXHash implementations in lz4-java 1.11.0 and earlier allows callers to crash the JVM by passing an invalid array reference or invalid range to native XXHash methods.&lt;/p&gt;
&lt;p&gt;This affects applications where an attacker can influence the byte array object or the `off` / `len` arguments passed to affected XXHash APIs. It does **not** affect the common case where only the contents of a valid byte array are attacker-controlled.&lt;/p&gt;
&lt;p&gt;Java-based XXHash implementations are *not* affected.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The JNI-backed XXHash implementations pass caller-provided byte array arguments to native code. The affected APIs are:&lt;/p&gt;
&lt;p&gt;- `XXHashFactory.nativeInstance().hash32().hash(byte[] buf, int off, int len, int seed)`
- `XXHashFactory.nativeInstance().hash64().hash(byte[] buf, int off, int len, long seed)`
- `XXHashFactory.nativeInstance().newStreamingHash32(seed).update(byte[] bytes, int off, int len)`
- `XXHashFactory.nativeInstance().newStreamingHash64(seed).update(byte[] bytes, int off, int len)`&lt;/p&gt;
&lt;p&gt;Before the fix, the streaming JNI implementations did not validate `bytes`, `off`, or `len` before calling `XXHashJNI.XXH32_update` / `XXHashJNI.XXH64_update`. The non-streaming JNI implementations called `SafeUtils.checkRange`, but `SafeUtils.checkRange(byte[], int, int)` skipped all array access when `len == 0`, so a null byte array with a zero length could still reach JNI.&lt;/p&gt;
&lt;p&gt;As a result:&lt;/p&gt;
&lt;p&gt;- `hash(null, 0, 0, seed)` and `update(null…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Maven: at.yawk.lz4:lz4-java, Maven: org.lz4:lz4-java&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;Insufficient validation of byte array arguments in JNI-based XXHash implementations in lz4-java 1.11.0 and earlier allows callers to crash the JVM by passing an invalid array reference or invalid range to native XXHash methods.&lt;/p&gt;
&lt;p&gt;This affects applications where an attacker can influence the byte array object or the `off` / `len` arguments passed to affected XXHash APIs. It does **not** affect the common case where only the contents of a valid byte array are attacker-controlled.&lt;/p&gt;
&lt;p&gt;Java-based XXHash implementations are *not* affected.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;The JNI-backed XXHash implementations pass caller-provided byte array arguments to native code. The affected APIs are:&lt;/p&gt;
&lt;p&gt;- `XXHashFactory.nativeInstance().hash32().hash(byte[] buf, int off, int len, int seed)`
- `XXHashFactory.nativeInstance().hash64().hash(byte[] buf, int off, int len, long seed)`
- `XXHashFactory.nativeInstance().newStreamingHash32(seed).update(byte[] bytes, int off, int len)`
- `XXHashFactory.nativeInstance().newStreamingHash64(seed).update(byte[] bytes, int off, int len)`&lt;/p&gt;
&lt;p&gt;Before the fix, the streaming JNI implementations did not validate `bytes`, `off`, or `len` before calling `XXHashJNI.XXH32_update` / `XXHashJNI.XXH64_update`. The non-streaming JNI implementations called `SafeUtils.checkRange`, but `SafeUtils.checkRange(byte[], int, int)` skipped all array access when `len == 0`, so a null byte array with a zero length could still reach JNI.&lt;/p&gt;
&lt;p&gt;As a result:&lt;/p&gt;
&lt;p&gt;- `hash(null, 0, 0, seed)` and `update(null…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-xx22-p4ch-683r</guid>
    </item>
    <item>
      <title>OESA-2026-4077 — lz4-java security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-4077</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: lz4-java&lt;/p&gt;
&lt;p&gt;LZ4 compression for Java, based on Yann Collet&amp;amp;amp;apos;s work. This library provides access to two compression methods that both generate a valid LZ4 stream: * fast scan (LZ4):     ° low memory footprint (~ 16 KB),     ° very fast (fast scan with skipping heuristics in case the       input looks incompressible),     ° reasonable compression ratio (depending on the       redundancy of the input). * high compression (LZ4 HC):     ° medium memory footprint (~ 256 KB),     ° rather slow (~ 10 times slower than LZ4),     ° good compression ratio (depending on the size and       the redundancy of the input). The streams produced by those 2 compression algorithms use the same compression format, are very fast to decompress and can be decompressed by the same decompressor instance.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1.(CVE-2026-59949)&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: lz4-java&lt;/p&gt;
&lt;p&gt;LZ4 compression for Java, based on Yann Collet&amp;amp;amp;apos;s work. This library provides access to two compression methods that both generate a valid LZ4 stream: * fast scan (LZ4):     ° low memory footprint (~ 16 KB),     ° very fast (fast scan with skipping heuristics in case the       input looks incompressible),     ° reasonable compression ratio (depending on the       redundancy of the input). * high compression (LZ4 HC):     ° medium memory footprint (~ 256 KB),     ° rather slow (~ 10 times slower than LZ4),     ° good compression ratio (depending on the size and       the redundancy of the input). The streams produced by those 2 compression algorithms use the same compression format, are very fast to decompress and can be decompressed by the same decompressor instance.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1.(CVE-2026-59949)&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-4077</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-59949</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-59949</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:20.04:LTS: lz4-java, Ubuntu:22.04:LTS: lz4-java, Ubuntu:24.04:LTS: lz4-java, Ubuntu:26.04:LTS: lz4-java&lt;/p&gt;
&lt;p&gt;yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:20.04:LTS: lz4-java, Ubuntu:22.04:LTS: lz4-java, Ubuntu:24.04:LTS: lz4-java, Ubuntu:26.04:LTS: lz4-java&lt;/p&gt;
&lt;p&gt;yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-59949</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-3595 — IBM QRadar SIEM: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3595</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in IBM QRadar SIEM ausnutzen, um beliebigen Programmcode auszuführen, um seine Privilegien zu erhöhen, um einen Denial of Service Angriff durchzuführen, um Informationen offenzulegen, um Dateien zu manipulieren, um einen Cross-Site Scripting Angriff durchzuführen und um Sicherheitsvorkehrungen zu umgehen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in IBM QRadar SIEM ausnutzen, um beliebigen Programmcode auszuführen, um seine Privilegien zu erhöhen, um einen Denial of Service Angriff durchzuführen, um Informationen offenzulegen, um Dateien zu manipulieren, um einen Cross-Site Scripting Angriff durchzuführen und um Sicherheitsvorkehrungen zu umgehen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-3595</guid>
    </item>
  </channel>
</rss>
