High-Severity lz4-java Flaw (CVE-2025-66566) Leaks Uninitialized Memory During Decompression
Ddos 
A high-severity vulnerability has been unearthed in lz4-java, a widely used Java library for the LZ4 compression algorithm. Tracked as CVE-2025-66566, the flaw carries a CVSS score of 8.2, signaling a significant risk to data confidentiality. The vulnerability allows attackers to trick the decompressor into reading and exposing uninitialized memory—potentially leaking sensitive data left over from previous operations.
The core of the issue lies in how the library handles output buffers during the decompression process. According to the advisory, “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”.
The LZ4 algorithm is built for speed, often achieving this by repeating data that has already been decompressed. However, the Java implementation of this logic has a critical blind spot.
In a standard attack scenario, a threat actor provides a manipulated input frame. “With a crafted input, an attacker may induce the Java implementation to copy from a region in the output buffer that does not contain decompressed data yet”.
If an application reuses output buffers to save memory—a common performance optimization—the “dirty” parts of that buffer might still hold passwords, cryptographic keys, or user data from a previous session. The advisory warns: “If that region contains sensitive information because the output buffer was not cleared prior to decompression, that data will then be copied to the decompressed output”.
Not all implementations of lz4-java are affected. The advisory explicitly states that “JNI-based implementations are not affected”. However, determining if your application is safe requires a close look at which factory method you are calling.
The Danger Zones:
- Pure Java Implementations: Both LZ4Factory.safeInstance() and LZ4Factory.unsafeInstance() are fully affected.
- The “Fastest” Trap: Developers using LZ4Factory.fastestInstance() might assume they are using safe native code. However, if the platform is unsupported and JNI cannot be used, it falls back to the vulnerable Java implementation.
- The “Fast” Decompressor: Specifically, LZ4Factory.nativeInstance().fastDecompressor() is affected because, ironically, it has been using the vulnerable safeInstance() logic since version 1.8.1.
The severity of this flaw is context-dependent. “Users that allocate a new destination buffer each time, or use only zeroed buffers, are not impacted”. However, for high-performance applications that recycle memory, the risk is acute.
The maintainers have released a patch. “Iz4-java 1.10.1 fixes this issue without requiring changes in user code”.
If an immediate upgrade is not possible, developers can manually neutralize the threat. “If you cannot upgrade to 1.10.1, you can mitigate this vulnerability by zeroing the output buffer before passing it to the decompression function”.
Donate