CVE-2026-106453 · GHSA-6cx8-rjf8-pr8g
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
- Risk score
- 43/100
- CVSS
- 5.3 v3.1
- Exploit chance (30 days)
- 0.4%
- Published
- 6 Oct 2026
Open in the live forecast Today's forecast
What to know
- What it is
- yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, LZ4DecompressorWithLength uses getDecompressedLength to trust the four-byte decompressed-length header before validating the compressed input, allowing a five-byte attacker-supplied input whose header declares a large output size to request up to appr…
- Affected
- at.yawk.lz4:lz4-java (maven) <= 1.11.1; org.lz4:lz4-java (maven) <= 1.8.1
- Fix
- Upgrade at.yawk.lz4:lz4-java to 1.11.2 or later.
- Exploitation
- No known exploitation
Story map
At a glance
at.yawk.lz4:lz4-java: Yellow, plan it in. 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, allowi…
The flaws
- CVE-2026-106453: 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 (CVSS 5.3 · EPSS 0%)
- CVE-2026-106451: Yawkat LZ4 Java: Native library extraction to a shared temporary directory is vulnerable to file replacement by another local user (CVSS 7.3 · EPSS 0%)
- CVE-2026-106450: Yawkat LZ4 Java: LZ4FrameInputStream reallocates block buffers for every frame, allowing CPU and GC amplification from small inputs (CVSS 5.3 · EPSS 0%)
- CVE-2026-106452: Yawkat LZ4 Java: LZ4BlockInputStream allocates an unvalidated compressed length from the stream header (CVSS 5.3 · EPSS 0%)
The fix
Upgrade at.yawk.lz4:lz4-java: 1.11.2 · 1.11.4 or later on your release line
Who is exposed: at.yawk.lz4:lz4-java (maven) <= 1.11.3; org.lz4:lz4-java (maven) >= 1.7.0, <= 1.8.1
Where it stands
- No known exploitation
Connects to
- Same weakness: CWE-789 (CWE-789). 44 other warnings in 30 days
Why it is Yellow
- CVSS 5.3 medium
- On your watchlist: Maven
Affected packages
| Package | Ecosystem | Vulnerable | Fixed in |
|---|---|---|---|
| at.yawk.lz4:lz4-java | maven | <= 1.11.1 | 1.11.2 |
| org.lz4:lz4-java | maven | <= 1.8.1 | No fix yet |
References
- https://github.com/advisories/GHSA-6cx8-rjf8-pr8g
- https://github.com/yawkat/lz4-java/security/advisories/GHSA-6cx8-rjf8-pr8g
- https://nvd.nist.gov/vuln/detail/CVE-2026-106453
- https://github.com/yawkat/lz4-java/commit/6492ce5aca6bd03ff9e08ee18a2beb94c431371a
- https://github.com/yawkat/lz4-java/releases/tag/v1.11.2
- https://github.com/advisories/GHSA-6cx8-rjf8-pr8g
Original description
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, LZ4DecompressorWithLength uses getDecompressedLength to trust the four-byte decompressed-length header before validating the compressed input, allowing a five-byte attacker-supplied input whose header declares a large output size to request up to approximately 2 GiB and exhaust the JVM heap. Convenience overloads backed by LZ4FastDecompressor or LZ4SafeDecompressor allocate the untrusted size, while overloads that write to a caller-provided destination buffer are not affected because the caller controls the destination size. This issue is fixed in version 1.11.2.
Last activity 6 Oct 2026. Patch Forecast updates every hour.