CVE-2026-106450: 
Java vulnerability analysis and mitigation

CVE-2026-106450 is a Denial of Service vulnerability in yawkat's lz4-java library caused by uncontrolled memory allocation in LZ4FrameInputStream.readHeader(). The flaw affects all versions of at.yawk.lz4:lz4-java up to and including 1.11.3, and org.lz4:lz4-java up to and including 1.8.1 (no patch available for the latter). It was disclosed on September 25, 2026 via a GitHub Security Advisory and assigned CVE-2026-106450 on October 6, 2026. The vulnerability carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling). In net.jpountz.lz4.LZ4FrameInputStream.readHeader(), two new byte arrays of up to 4 MiB each (compressedBuffer and rawBuffer) are allocated every time a frame header is read, without reusing buffers from prior frames. Because the default mode reads concatenated frames, an attacker can craft a stream of many minimal valid empty frames — each only 11 bytes long (magic number, FLG 0x60, BD 0x70, header checksum, end mark) — to trigger approximately 8 MiB of heap allocation per 11 input bytes. The stream produces no decompressed output, so decompressed-size limits are ineffective as a mitigation. In local measurements on JDK 25, 10,000 such frames (110 KB of input) consumed approximately 8 seconds of CPU time, roughly 70 seconds per MiB of input, across G1, Parallel, Serial, and ZGC garbage collectors. The readSingleFrame = true mode is not affected because it performs only a single allocation (GitHub Advisory, Patch Commit).

Successful exploitation results in a Denial of Service affecting availability only — there is no confidentiality or integrity impact. An unauthenticated remote attacker can send a small crafted LZ4-compressed stream to exhaust CPU and trigger excessive garbage collection, degrading or halting service for legitimate users. Live heap usage stays bounded at approximately 8 MiB, but CPU and GC overhead scale linearly with the size of the compressed input accepted by the application, making the practical impact proportional to the application's input size limits (GitHub Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation at this time. The vulnerability requires no authentication, no user interaction, and low attack complexity, making it straightforward to exploit if an attacker can supply LZ4-compressed data to a vulnerable application. The EPSS score is 0.0, reflecting the current absence of observed exploitation activity. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (GitHub Advisory, Feedly).

1. Identify target: Locate applications that accept attacker-controlled LZ4-compressed data and use LZ4FrameInputStream in default (concatenated-frame) mode with lz4-java versions ≤ 1.11.3.
2. Craft malicious stream: Construct a byte stream consisting of many minimal valid LZ4 frames. Each frame is 11 bytes: the 4-byte LZ4 magic number (0x04 0x22 0x4D 0x18), FLG byte 0x60 (version 01, block independence), BD byte 0x70 (4 MiB max block size), a 1-byte header checksum, and a 4-byte end mark (0x00 0x00 0x00 0x00).
3. Amplify allocation: Repeat the 11-byte frame thousands of times. For example, 10,000 frames (110 KB total input) will trigger approximately 80 GB of cumulative heap allocation attempts and ~8 seconds of CPU time on JDK 25.
4. Submit to target: Send the crafted stream to any application endpoint that passes the data to new LZ4FrameInputStream(inputStream) without restricting the number of frames or using readSingleFrame = true.
5. Achieve DoS: The application's JVM spends excessive time in garbage collection and CPU processing, degrading or halting service for legitimate users while the attacker's input remains small (GitHub Advisory).

• Network: Repeated or sustained submissions of small LZ4-compressed payloads (≤ a few hundred KB) to application endpoints that accept compressed data; unusual traffic patterns where compressed input size is disproportionately small relative to processing time.
• Application/JVM Logs: Sudden spikes in garbage collection frequency and duration logged by the JVM (e.g., GC pause times increasing dramatically); application thread dumps showing threads blocked in LZ4FrameInputStream.readHeader() or related GC activity.
• System Metrics: Sustained high CPU utilization on the Java process without corresponding increase in decompressed output or application throughput; JVM heap allocation rate anomalies visible in monitoring tools (e.g., JMX, JVM flight recorder) showing repeated ~8 MiB allocation bursts.
• Application Behavior: Service degradation or unresponsiveness correlated with receipt of LZ4-compressed input; no corresponding increase in decompressed data volume processed (GitHub Advisory).

The primary remediation is to upgrade at.yawk.lz4:lz4-java to version 1.11.4, which fixes the issue by allocating block buffers lazily on the first block and reusing them across frames rather than reallocating on every frame header read. The fix also reuses the content checksum hash and skippable-frame skip buffer across frames. For org.lz4:lz4-java, no patched version is currently available. As interim workarounds: (1) switch to readSingleFrame = true mode where application logic permits, as this mode is unaffected; (2) enforce strict limits on the size of compressed input accepted from untrusted sources; or (3) implement rate limiting and frame-count validation on incoming LZ4 data (GitHub Advisory, Release v1.11.4, Patch Commit).