CVE-2026-106450 in lz4-java
Summary
by MITRE • 10/06/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in yawkat LZ4 Java prior to version 1.11.4 represents a significant resource exhaustion flaw rooted in the implementation of the LZ4 compression library for the Java platform. Specifically, the issue resides within the net.jpountz.lz4.LZ4FrameInputStream class and its readHeader method. This component is responsible for parsing frame headers during decompression operations. The core technical flaw occurs when the stream encounters a maximum-block-size frame header. In such cases, the implementation allocates two new block buffers, each sized at 4 MiB, resulting in an immediate allocation of approximately 8 MiB of heap memory per occurrence. This behavior is intrinsic to how the library handles specific LZ4 frame structures and does not account for the volume or frequency of these headers within a single stream context.
The operational impact is exacerbated by the default configuration of the library, which operates in concatenated-frame mode. In this mode, an attacker can craft malicious input streams consisting of many minimal empty frames that each contain a maximum-block-size header indicator. Because the decompression process attempts to allocate memory for every such frame regardless of whether actual data follows, it triggers the aforementioned 8 MiB allocation repeatedly. The efficiency of this attack is high; approximately 11 bytes of attacker-controlled input can trigger nearly 8 MiB of memory consumption. This disproportionate ratio means that even a relatively small amount of network traffic or file upload volume can rapidly deplete available system resources.
A critical aspect of this vulnerability is its resistance to standard decompression-size mitigation strategies. Typically, applications attempt to prevent resource exhaustion by limiting the total size of decompressed output. However, in this scenario, the stream produces no actual decompressed data because the frames are empty or minimal. Consequently, while the application consumes significant CPU cycles and garbage collection time due to the massive allocation pressure, it generates zero useful output. This renders traditional limits on decompressed file sizes ineffective as a defense mechanism against this specific attack vector. The system continues to allocate memory and process input until either an OutOfMemoryError is thrown or the service becomes unresponsive due to excessive garbage collection pauses.
The vulnerability specifically affects the concatenated-frame mode, which allows multiple LZ4 frames to be processed sequentially within a single stream. This mode is commonly used in streaming scenarios where data arrives in chunks over time. The readSingleFrame mode is not affected by this issue because it processes only one frame and does not exhibit the same repetitive allocation pattern for subsequent headers. However, given that concatenated-frame processing is often the default or preferred method for handling compressed streams in many Java applications, the exposure surface remains broad. Attackers can leverage this flaw to execute Denial of Service attacks against any service relying on yawkat LZ4 Java versions prior to 1.11.4 for decompressing untrusted input data.
From a classification perspective, this vulnerability aligns with CWE-789: Memory Allocation with Excessive Size Value and CWE-400: Uncontrolled Resource Consumption. The attack vector is consistent with ATT&CK technique T1496: Resource Hijacking, where an adversary consumes resources to degrade service availability. To mitigate this risk, organizations must upgrade the yawkat LZ4 Java library to version 1.11.4 or later, which addresses the excessive allocation behavior in the readHeader method. Additionally, until migration is complete, developers should consider implementing strict input validation and size limits on the compressed stream itself rather than relying solely on decompressed output limits. Monitoring for unusually high garbage collection activity associated with LZ4 processing can also serve as an early detection mechanism for potential exploitation attempts.