Advisories for Maven/Org.lz4/Lz4-Java package

2026

yawkat LZ4 Java: Native library extraction to a shared temporary directory is vulnerable to file replacement by another local user

When no system-installed liblz4-java is found, net.jpountz.util.Native.load() extracts the bundled native library to java.io.tmpdir and loads it with System.load. The path of the extracted library can be predicted before it is created, and the library file is opened without exclusive creation. Another local user who can write to the same temporary directory can therefore create the file first and control the code that is loaded.

yawkat LZ4 Java: LZ4FrameInputStream reallocates block buffers for every frame, allowing CPU and GC amplification from small inputs

LZ4FrameInputStream allocates two new buffers of the frame'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.

yawkat LZ4 Java: LZ4DecompressorWithLength allocates the unvalidated size from the 4-byte length header, so a 5-byte input triggers a 1 GiB allocation and OutOfMemoryError

LZ4DecompressorWithLength.decompress(byte[], int) allocates whatever size the 4-byte length header declares, before it reads a single byte of compressed data. A 5-byte input whose header says 0x40000000 makes the JVM commit a gigabyte and can cause heap exhaustion.

yawkat LZ4 Java: LZ4BlockInputStream with stopOnEmptyBlock=false recurses once per empty block, causing StackOverflowError

When LZ4BlockInputStream is configured with stopOnEmptyBlock = false (the mode for reading concatenated block streams), it handles each empty block by calling refill() recursively. A long run of empty blocks exhausts the thread stack and throws StackOverflowError out of read() or skip().

yawkat LZ4 Java: LZ4BlockInputStream allocates an unvalidated compressed length from the stream header

LZ4BlockInputStream grows its compressed-input buffer to the attacker-controlled compressedLen value from the legacy LZ4Block stream header before reading any payload bytes. A header-only input can therefore trigger a near-2 GiB allocation and exhaust the JVM heap.

LZ4 Java: Native XXHash implementations can crash the JVM when passed invalid byte array ranges

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. 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 …

2025

yawkat LZ4 Java has a possible information leak in Java safe decompressor

Insufficient clearing of the output buffer in Java-based decompressor implementations in lz4-java 1.10.0 and earlier allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data. JNI-based implementations are not affected.

LZ4 Java Compression has Out-of-bounds memory operations which can cause DoS

Out-of-bounds memory operations in org.lz4:lz4-java 1.8.0 and earlier allow remote attackers to cause denial of service and read adjacent memory via untrusted compressed input. This is fixed in a forked release: at.yawk.lz4:lz4-java version 1.8.1. The original project has been archived: https://github.com/lz4/lz4-java, and Sonatype has added a redirect from org.lz4:lz4-java:1.8.1 to the new group ID.