LZ4 Java CVE-2026-106453

The application must pass attacker-controlled compressed data to LZ4DecompressorWithLength's allocating convenience overloads - specifically decompress(byte[]) / decompress(byte[], int) backed by an LZ4FastDecompressor or LZ4SafeDecompressor - which allocate an output buffer sized from the untrusted four-byte header before validating the compressed payload. Exploitation is LIMITED by several factors: overloads that write into a caller-provided destination buffer are NOT affected because the caller controls the destination size; the allocation is capped near 2 GiB by a signed 32-bit length, bounding impact to transient heap pressure/OutOfMemoryError rather than unbounded allocation; and the affected version must be prior to 1.11.2. No special product configuration flag is required beyond the use of the vulnerable allocating API on untrusted input.

This is a moderate, availability-only issue that is correctly rated low-to-medium rather than a genuine high-priority emergency. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, base 5.3) indicates a network-reachable, low-complexity, unauthenticated flaw with no confidentiality or integrity impact and only LOW availability impact - consistent with CWE-789 (memory allocation with excessive size value) and the description's uncontrolled ~2 GiB heap allocation. The impact is bounded: a signed 32-bit length caps the allocation at roughly 2 GiB per request, so this is a resource-exhaustion/denial-of-service primitive, not code execution or data leakage. No EPSS score, CISA KEV listing, or public POC was provided in the input, so there is no signal of active or widespread exploitation; by the precision rules this is 'no public exploit identified at time of analysis.' Signals are internally consistent except for the metadata 'Information Disclosure' tag, which directly contradicts the CVSS vector (C:N, I:N) and the description - this is memory exhaustion affecting availability, not information disclosure. Real-world risk is gated by whether an application actually feeds attacker-controlled compressed data into the vulnerable allocating overloads; where it does not, effective risk is negligible.

An application uses LZ4DecompressorWithLength's convenience decompress(byte[]) overload (backed by LZ4FastDecompressor or LZ4SafeDecompressor) to decompress data received from an untrusted source such as a network client or uploaded file. An attacker submits a tiny (~5-byte) input whose four-byte length header declares a size near 2 GiB; the library trusts the header before validating the compressed payload and allocates the full buffer, exhausting the JVM heap and triggering OutOfMemoryError. No public exploit code was identified in the provided data, though the technique is trivial given the described behavior.