CVE-2026-106451
HighCVSS 7.3Summary
The yawkat LZ4 Java library versions 1.7.0 through 1.11.4 contain a vulnerability in the insecure creation of a temporary file. An attacker with access to a shared temporary directory can replace the native library file before it is loaded, potentially leading to code execution in the victim's context.
Risk Assessment
The risk includes local privilege escalation or execution of malicious code on the victim's machine. A successful attack requires specific conditions, but if exploited, it can fully compromise the system.
Recommendation
It is recommended to upgrade immediately to version 1.11.4, which fixes the vulnerability. Additionally, consider using a private temporary directory or a system library.
Other vulnerabilities in yawkat LZ4 Java
See all- CVE-2026-106453Medium
In yawkat LZ4 Java prior to 1.11.2, LZ4DecompressorWithLength trusts the four-byte decompressed-length header before validating input, allowing a five-byte input to request up to ~2 GiB and exhaust the JVM heap. Overloads writing to a caller-provided buffer are not affected.
- CVE-2026-106452Medium
In yawkat LZ4 Java prior to 1.11.2, LZ4BlockInputStream.refill() validates the compressedLen field as nonnegative but allocates a buffer of that attacker-controlled size before reading payload data. A header-only stream can request a near-2 GiB allocation and exhaust the JVM heap.
- CVE-2026-106450Medium
In yawkat LZ4 Java prior to 1.11.4, LZ4FrameInputStream.readHeader() allocates two 4 MiB block buffers for maximum-block-size frame headers, and the default concatenated-frame mode allows streams with many minimal empty frames to trigger ~8 MiB allocation per 11 input bytes without producing output.
- CVE-2026-106449Low
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, net.jpountz.lz4.LZ4BlockInputStream configured with stopOnEmptyBlock set to false handles each well-formed empty LZ4Block by recursively calling refill(), allowing a long sequence of empty blocks in an attacker-controlled compressed stream to exhaust the decoding thread's stack and throw StackOverflowError. The default stopOnEmptyBlock setting is true and is not affected, and the issue does not cause memory corruption.
- CVE-2026-59949Medium
In yawkat LZ4 Java before version 1.11.1, JNI-backed XXHash functions fail to validate the byte array and off/len arguments, allowing null arrays or oversized ranges to reach native code. This can cause reads outside the Java array and fatal JVM termination. Fixed in version 1.11.1.
Original NVD description (English source)
yawkat LZ4 Java provides LZ4 compression for Java. From 1.7.0 until 1.11.4, net.jpountz.util.Native.load() uses File.createTempFile to create an exclusive temporary .lck file but derives the native-library path by removing the suffix, then FileOutputStream opens that predictable path without exclusive creation, allowing another local user with access to the same shared temporary directory to create or replace the library file before System.load() uses it. Successful exploitation depends on shared-directory permissions, host protections, and winning the race, and can execute native code as the victim; hardened systems may instead cause library loading to fail and fall back to Java implementations. Configurations using a system library, a private java.io.tmpdir, or Java-only implementations are not affected. This issue is fixed in version 1.11.4.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS