LZ4 Java EUVD-2026-93871

The consuming application must use net.jpountz.lz4.LZ4BlockInputStream (or its Builder) to decompress LZ4 legacy-block data that an attacker can influence; against that default configuration no authentication or user interaction is required, since refill() validates only that compressedLen is nonnegative and allocates the buffer before reading payload. The concrete prerequisite is an attacker-supplied non-canonical legacy LZ4Block header whose compressedLen is set greater than or equal to originalLen (up to ~2 GiB) - canonical writers never emit such blocks, so the attacker must forge one. Limiting factors: the vulnerability is only reachable if the application exposes this reader to untrusted compressed input; version 1.11.2+ rejects oversized blocks by default and only reintroduces the risk if an operator explicitly calls withAcceptOversizedBlocks(true), and effective impact depends on the JVM's configured maximum heap relative to the ~2 GiB request.

This is a memory-allocation denial-of-service flaw (CWE-789), not a priority emergency. The provided CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L = 5.3 MEDIUM) is internally consistent with the description: a remote, unauthenticated, low-complexity trigger with availability-only impact and no confidentiality or integrity loss. No EPSS score, no CISA KEV listing, and no standalone public exploit were provided, so exploitation is currently 'no public exploit identified at time of analysis' - though the fix commit (bb83dd1) ships a regression test that demonstrates the oversized-block code path. The signals are non-conflicting and all point to a moderate resource-exhaustion issue rather than code execution: the A:L rating reflects that a single crafted header forces one ~2 GiB heap allocation (transient failure) rather than guaranteed process death, but note that on JVMs with max heap below ~2 GiB the resulting OutOfMemoryError can realistically crash or destabilize the host application, which would push real-world impact toward A:H. Exploitability is entirely gated by whether the consuming application feeds attacker-controlled LZ4 legacy-block streams into LZ4BlockInputStream; the library default is vulnerable (the patch rejects non-canonical oversized blocks unless the new withAcceptOversizedBlocks(true) opt-in is set). Caveat: the input Tag 'Information Disclosure' directly contradicts the CVSS vector (C:N/I:N) - this is an availability/DoS issue, so that label should not drive triage.

An attacker who can submit LZ4-compressed data to a service that decompresses it via net.jpountz.lz4.LZ4BlockInputStream crafts a header-only legacy LZ4Block whose compressedLen field is set near 2 GiB. Because refill() only checks that the value is nonnegative and allocates the compressed-input buffer before reading any payload, a tiny request forces a massive JVM heap allocation, risking OutOfMemoryError and service disruption. No weaponized public exploit is known, but the vendor's fix commit includes a regression test exercising this exact oversized-block path.