<?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://db.gcve.eu</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, 08 Oct 2026 19:36:27 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-106450</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-106450</link>
      <description>&lt;p&gt;yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, net.jpountz.lz4.LZ4FrameInputStream readHeader() allocates two new 4 MiB block buffers whenever a maximum-block-size frame header is read, and the default concatenated-frame mode allows attacker-controlled streams containing many minimal empty frames to trigger roughly 8 MiB of allocation for every 11 input bytes. The stream produces no decompressed output while consuming CPU and garbage-collection time, so decompressed-size limits do not mitigate the issue; readSingleFrame mode is not affected. This issue is fixed in version 1.11.4.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, net.jpountz.lz4.LZ4FrameInputStream readHeader() allocates two new 4 MiB block buffers whenever a maximum-block-size frame header is read, and the default concatenated-frame mode allows attacker-controlled streams containing many minimal empty frames to trigger roughly 8 MiB of allocation for every 11 input bytes. The stream produces no decompressed output while consuming CPU and garbage-collection time, so decompressed-size limits do not mitigate the issue; readSingleFrame mode is not affected. This issue is fixed in version 1.11.4.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-106450</guid>
    </item>
    <item>
      <title>GHSA-gm45-99xc-r7wv — yawkat LZ4 Java: LZ4FrameInputStream reallocates block buffers for every frame, allowing CPU and GC amplification from…</title>
      <link>https://db.gcve.eu/vuln/ghsa-gm45-99xc-r7wv</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;`LZ4FrameInputStream` allocates two new buffers of the frame&amp;#39;s maximum block size, up to 4 MiB each, every time it reads a frame header. Because concatenated frames are read by default, an input made of many minimal empty frames forces about 8 MiB of zeroed heap allocation for every 11 input bytes.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;In `net.jpountz.lz4.LZ4FrameInputStream.readHeader()`:&lt;/p&gt;
&lt;p&gt;```java
maxBlockSize = frameInfo.getBD().getBlockMaximumSize();
compressedBuffer = new byte[maxBlockSize]; // Reused during different compressions
rawBuffer = new byte[maxBlockSize];
buffer = ByteBuffer.wrap(rawBuffer);
```&lt;/p&gt;
&lt;p&gt;This runs for every frame, and the previous frame&amp;#39;s arrays are never reused. A valid 11-byte frame consists of the magic number, FLG `0x60`, BD `0x70` (4 MiB blocks), the header checksum, and an immediate end mark. It carries no data, yet triggers the full 8 MiB allocation. `new LZ4FrameInputStream(in)` reads concatenated frames by default.&lt;/p&gt;
&lt;p&gt;In local measurements on JDK 25, 10,000 such frames (110 KB of input) took about 8 seconds of CPU to read, roughly 70 seconds per MiB of input. This was similar under G1, Parallel, Serial and ZGC. A legitimate stream costs orders of magnitude less per input byte.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Applications that decode attacker-controlled LZ4 frame data with `LZ4FrameInputStream` can be made to spend large amounts of CPU and GC time relative to the input size. Live heap stays bounded at about 8 MiB and the stream produces no output, so decompressed-size limits…&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;`LZ4FrameInputStream` allocates two new buffers of the frame&amp;#39;s maximum block size, up to 4 MiB each, every time it reads a frame header. Because concatenated frames are read by default, an input made of many minimal empty frames forces about 8 MiB of zeroed heap allocation for every 11 input bytes.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;In `net.jpountz.lz4.LZ4FrameInputStream.readHeader()`:&lt;/p&gt;
&lt;p&gt;```java
maxBlockSize = frameInfo.getBD().getBlockMaximumSize();
compressedBuffer = new byte[maxBlockSize]; // Reused during different compressions
rawBuffer = new byte[maxBlockSize];
buffer = ByteBuffer.wrap(rawBuffer);
```&lt;/p&gt;
&lt;p&gt;This runs for every frame, and the previous frame&amp;#39;s arrays are never reused. A valid 11-byte frame consists of the magic number, FLG `0x60`, BD `0x70` (4 MiB blocks), the header checksum, and an immediate end mark. It carries no data, yet triggers the full 8 MiB allocation. `new LZ4FrameInputStream(in)` reads concatenated frames by default.&lt;/p&gt;
&lt;p&gt;In local measurements on JDK 25, 10,000 such frames (110 KB of input) took about 8 seconds of CPU to read, roughly 70 seconds per MiB of input. This was similar under G1, Parallel, Serial and ZGC. A legitimate stream costs orders of magnitude less per input byte.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Applications that decode attacker-controlled LZ4 frame data with `LZ4FrameInputStream` can be made to spend large amounts of CPU and GC time relative to the input size. Live heap stays bounded at about 8 MiB and the stream produces no output, so decompressed-size limits…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-gm45-99xc-r7wv</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-106450</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-106450</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.4, ne ...)&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.4, ne ...)&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-106450</guid>
    </item>
  </channel>
</rss>
