CVE-2026-106453 in lz4-java
Summary
by MITRE • 10/06/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability identified in yawkat LZ4 Java prior to version 1.11.2 represents a critical resource exhaustion flaw rooted in improper validation of untrusted input data during the decompression process. The library, which provides high-performance LZ4 compression and decompression capabilities for Java applications, contains a specific implementation defect within the LZ4DecompressorWithLength class. This component is responsible for handling compressed streams that include a length header indicating the size of the uncompressed output. In vulnerable versions, the code prioritizes convenience by immediately invoking getDecompressedLength to determine the required buffer size based on this four-byte header before performing any validation checks on the actual compressed input data.
This architectural decision creates a significant security gap because it trusts external metadata without verifying its integrity or consistency with the provided payload. An attacker can craft a maliciously small input consisting of only five bytes where the embedded length header declares an excessively large decompressed size, such as close to 2 GiB. Because the library allocates memory for this declared output size immediately upon invocation, it triggers a massive allocation request on the Java Virtual Machine heap. This behavior is particularly dangerous because standard LZ4 compression typically results in outputs that are equal to or smaller than inputs; therefore, a small input claiming a huge output is an immediate indicator of malformed or malicious data that should be rejected early in the processing pipeline.
The operational impact of this vulnerability is severe, leading directly to Denial of Service conditions through heap exhaustion and subsequent application crashes. When the JVM attempts to allocate several gigabytes of memory for a trivial five-byte input, it quickly depletes available heap space. This results in OutOfMemoryError exceptions that can crash the entire Java process or degrade performance significantly if garbage collection struggles with the massive allocation attempt. The vulnerability specifically affects convenience overloads backed by LZ4FastDecompressor and LZ4SafeDecompressor which automatically allocate buffers based on untrusted headers. However, it is important to note that overloads allowing callers to provide their own destination buffers are not vulnerable because they do not perform automatic memory allocation based solely on the header value; instead, they rely on pre-allocated space controlled by the application developer.
From a classification perspective, this vulnerability aligns with CWE-400: Uncontrolled Resource Consumption and CWE-20: Improper Input Validation. The failure to validate that the decompressed length is reasonable relative to the compressed input size constitutes an improper validation of untrusted data. In terms of attack vectors, this flaw can be exploited in scenarios where user-controlled or externally sourced LZ4-compressed data is processed by a server-side application without prior sanitization. This maps closely to ATT&CK technique T1496: Resource Hijacking, specifically the sub-technique for CPU or Memory Consumption, as well as aspects of T1529: System Shutdown/Reboot if the resulting crash leads to service unavailability in a production environment.
To mitigate this vulnerability, organizations must upgrade yawkat LZ4 Java to version 1.11.2 or later, where the developers have corrected the logic to validate compressed input integrity before allocating memory for decompression. For applications unable to immediately update dependencies, defensive coding practices should be implemented by avoiding convenience overloads that auto-allocate buffers when processing untrusted data. Instead, developers should use methods that accept pre-sized destination buffers and manually verify that the declared output length is within acceptable bounds relative to the input size before initiating decomposition. Additionally, implementing strict limits on maximum allowed decompression sizes at the application level can provide an additional layer of defense against resource exhaustion attacks targeting this class of vulnerabilities.