CVE-2026-106450 yawkat CVE debrief

Who should care

Defenders who use the LZ4 Java library in their applications should be aware of this vulnerability and take steps to verify and upgrade their versions if necessary. This includes developers, system administrators, and security teams.

Why it matters

This vulnerability can lead to performance issues and potential denial-of-service attacks due to excessive memory allocation and CPU amplification. Defenders should verify and upgrade their versions of the LZ4 Java library if necessary.

• Denial-of-service attacks through CPU and GC amplification
• Performance issues due to excessive memory allocation
• Potential for exploitation through specially crafted inputs

Technical summary

The LZ4FrameInputStream class in the LZ4 Java library allocates two new buffers of up to 4 MiB each every time it reads a frame header. This can lead to CPU and GC amplification from small inputs, potentially causing performance issues and denial-of-service attacks. A valid 11-byte frame consists of the magic number, FLG 0x60, BD 0x70 (4 MiB blocks), the header checksum, and an immediate end mark. It carries no data, yet triggers the full 8 MiB allocation. new LZ4FrameInputStream(in) reads concatenated frames by default. In local measurements on JDK 25, 10,000 such frames (110 KB of input) took about 8 seconds of CPU to read, roughly 70 seconds per MiB of input. This was similar under G1, Parallel, Serial and Z

Defensive priority

Defenders should prioritize verifying the version of the LZ4 Java library used in their applications and upgrading to version 1.11.4 or later if necessary. Additionally, defenders should monitor their applications for unusual performance issues that may be related to this vulnerability.

Recommended defensive actions

• Verify the version of the LZ4 Java library used in your applications
• Upgrade to version 1.11.4 or later if necessary
• Monitor applications for unusual performance issues
• Review compensating controls for exposed systems while remediation is scheduled and verified
• Check relevant monitoring, detection, and logs for exposed assets that need extra review
• Track exceptions, retest remediated assets, and close the item only after evidence is documented
• Confirm whether affected product deployments exist in managed environments and assign an owner for follow-up

Evidence notes

The evidence for this vulnerability comes from the OSV Dev source item and the CVE Program record. The OSV Dev source item provides a detailed description of the vulnerability, including code snippets and performance measurements. The CVE Program record provides official CVE metadata.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.