A flaw in the LZ4DecompressorWithLength implementation trusts the four‑byte decompressed‑length header before validating the compressed data. An attacker can craft a five‑byte payload whose header requests a large output size, causing the library to allocate up to roughly 2 GiB of memory and trigger an OutOfMemoryError. This results in a denial of service by crashing the JVM process that is decompressing the data. The weakness is an input validation defect (CWE‑789).

The issue affects the yawkat lz4‑java library in all releases prior to version 1.11.2. Any Java application that uses LZ4DecompressorWithLength to decompress data from untrusted sources is vulnerable; overloads that write directly to a caller‑provided buffer are not impacted because the caller controls the destination size.

The CVSS score of 5.3 indicates moderate severity. No EPSS score is available, and the vulnerability is not listed in CISA KEV. The likely attack vector is via manipulated compressed input supplied to an application that uses the affected library, which could be local or remote depending on the application’s exposure. An attacker who can supply such input will cause the victim JVM to exhaust memory, potentially disrupting service availability.