CVE-2026-106450: yawkat LZ4 Java: LZ4FrameInputStream reallocates block buffers for every frame, allowing CPU and GC amplification from small inputs
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, net.jpountz.lz4.LZ4FrameInputStream readHeader() allocates two new 4 MiB block buffers whenever a maximum-block-size frame header is read, and the default concatenated-frame mode allows attacker-controlled streams containing many minimal empty frames to trigger roughly 8 MiB of allocation for every 11 input bytes. The stream produces no decompressed output while consuming CPU and garbage-collection time, so decompressed-size limits do not mitigate the issue; readSingleFrame mode is not affected. This issue is fixed in version 1.11.4.
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.4
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using yawkat LZ4 Java before 1.11.4 that process attacker-controlled LZ4 streams with LZ4FrameInputStream in its default concatenated-frame mode are exposed. Deployments using readSingleFrame mode are not affected.
What does an attacker need to exploit it?
An attacker needs to supply a crafted LZ4 input stream containing many minimal empty frames with maximum-block-size headers. No authentication or user interaction is required.
Will decompressed-size limits prevent the denial of service?
No. The crafted stream produces no decompressed output, while each small frame can cause roughly 8 MiB of allocation and associated CPU and garbage-collection work.
What is the remediation?
Upgrade yawkat LZ4 Java to version 1.11.4. If upgrading is not immediately possible, use readSingleFrame mode rather than the default concatenated-frame mode where applicable.