lz4-java EUVD-2026-93862

Exploitation requires the consuming application to use net.jpountz.lz4.LZ4BlockInputStream with stopOnEmptyBlock explicitly set to false - this is NOT the default (the default true is unaffected) and is the primary limiting factor. The attacker must also control, or be able to inject, the compressed LZ4 block stream fed to that input stream. Given those conditions, no authentication is needed (PR:N) and no user interaction is required, but the non-default configuration and the AC:H rating reflect that most deployments running defaults are not exposed. Impact is limited to crashing the single decoding thread via StackOverflowError (availability only); there is no confidentiality, integrity, or memory-corruption impact.

This is a genuinely low-priority issue despite being network-reachable. The supplied CVSS:3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L, score 3.7) aligns well with the description: unauthenticated and remote, but high complexity and limited to a partial availability impact with no confidentiality or integrity loss. The root cause is CWE-674 (uncontrolled recursion) leading to a StackOverflowError on the decoding thread - a denial-of-service of a single thread, not memory corruption (the description explicitly rules that out). Crucially, exploitation requires the non-default LZ4BlockInputStream configuration stopOnEmptyBlock=false; the default (true) is not affected, which is the main factor limiting real-world exposure and justifies AC:H. No EPSS score, KEV listing, or public exploit was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation. Note a metadata conflict: the input Tags include 'Buffer Overflow', but the description explicitly states the issue does not cause memory corruption and CWE-674 is uncontrolled recursion - the 'Buffer Overflow' label is inaccurate. The upstream commit ships a regression test that constructs a malicious stream of 1,000,000 empty blocks, demonstrating feasibility, but this is a project unit test rather than a weaponized public exploit.

An application decodes untrusted LZ4 block-stream data using LZ4BlockInputStream explicitly configured with stopOnEmptyBlock=false. An attacker supplying the compressed stream prepends a long run of well-formed empty LZ4 blocks; the stream handler recurses once per empty block via refill(), exhausting the thread's stack and throwing StackOverflowError, crashing the decoding thread. No public weaponized exploit is identified, though the vendor's fix commit includes a test that reproduces the condition.