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
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
yawkat LZ4 Javato a version that resolves this vulnerability.Fixed in 1.11.2
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications using lz4-java versions prior to 1.11.2 are exposed if they decompress attacker-supplied data through convenience overloads backed by LZ4FastDecompressor or LZ4SafeDecompressor. These overloads allocate a destination buffer based on the untrusted length header.
What does an attacker need to send to trigger the resource exhaustion?
An attacker needs to supply compressed input to an affected decompression path. A five-byte input with a crafted four-byte decompressed-length header can request a very large allocation, up to approximately 2 GiB, and exhaust the JVM heap.
Are all LZ4DecompressorWithLength overloads affected?
No. Overloads that write into a caller-provided destination buffer are not affected, because the caller controls the destination size rather than allocating from the untrusted header.
What can be done if upgrading is not immediately possible?
Avoid the convenience decompression overloads that allocate the output buffer from the encoded length. Use an overload that writes to a caller-provided destination buffer with a controlled size.
How can I determine whether remediation is needed?
Check whether the application uses lz4-java before version 1.11.2 and whether untrusted compressed input reaches convenience overloads backed by LZ4FastDecompressor or LZ4SafeDecompressor. Upgrading to version 1.11.2 addresses the issue.