Loading vulnerability…
Out-of-bounds Memory Access in lz4-java
CVE-2025-12183 is an out-of-bounds memory access vulnerability affecting org.lz4:lz4-java, org.lz4:lz4-pure-java, and net.jpountz.lz4:lz4 versions 1.8.0 and earlier. Multiple compression and decompression implementations lack adequate memory bounds checks, including the JNI-based fast decompressor using LZ4_decompress_fast and Java implementations using sun.misc.Unsafe. Processing attacker-controlled compressed input can cause denial of service or disclosure of adjacent memory. Java implementations that do not use sun.misc.Unsafe throw ArrayIndexOutOfBoundsException rather than performing the vulnerable out-of-bounds memory access.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation can disrupt the application processing compressed data and expose adjacent process memory, potentially disclosing sensitive information. Remote exploitation is possible when an application exposes a path for attacker-controlled compressed input to reach an affected implementation. Integrity compromise and arbitrary code execution are not established.
If you can’t patch tonight, do this now.
Until migration is complete, use safe implementations through safeInstance() or safeDecompressor() as appropriate, avoiding the JNI fast decompressor and Java implementations using sun.misc.Unsafe for untrusted input. Prevent untrusted compressed data from reaching vulnerable implementations where possible. Restrict input sources, impose input size limits, and isolate decompression services as defense-in-depth measures; these controls do not replace the fix.
Patch, then assume compromise.
Migrate from the discontinued original lz4-java project to the maintained community fork. Fixed releases include at.yawk.lz4:lz4-java versions 1.8.1 and 1.9.0. The org.lz4:lz4-java:1.8.1 artifact is a relocation POM directing consumers to at.yawk.lz4:lz4-java:1.8.1; subsequent releases use the new group ID. Replace affected legacy artifacts and update transitive dependencies accordingly. The fixed implementation substitutes safe alternatives and reserves explicitly insecure factory methods for trusted-input scenarios.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
6 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.