CVE-2026-106449: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-106449 is a denial-of-service vulnerability in yawkat's lz4-java library caused by uncontrolled recursion in LZ4BlockInputStream when configured with stopOnEmptyBlock=false. An unauthenticated remote attacker can craft a compressed stream containing a long sequence of empty LZ4 blocks, causing the decoding thread to exhaust its stack and throw a StackOverflowError. Affected versions are at.yawk.lz4:lz4-java ≤ 1.11.3 and org.lz4:lz4-java ≤ 1.8.1; the default configuration (stopOnEmptyBlock=true) is not affected. The vulnerability was published on October 6, 2026, and carries a CVSS v3.1 base score of 3.7 (Low) (GitHub Advisory, Red Hat Bugzilla).

The root cause is uncontrolled recursion (CWE-674) combined with resource allocation without limits (CWE-770) in net.jpountz.lz4.LZ4BlockInputStream.refill(). When stopOnEmptyBlock is set to false, each well-formed empty LZ4 block (21 bytes each) triggers a recursive call to refill() with no depth limit, adding one stack frame per block. In testing, approximately 10,000 to 100,000 consecutive empty blocks (roughly 210 KB to 2.1 MB of input) are sufficient to trigger a StackOverflowError. Because StackOverflowError is a Java Error rather than an IOException, callers that only catch I/O exceptions for corrupt input will not handle it, potentially causing unhandled thread termination. The fix in version 1.11.4 replaces the recursive call with an iterative loop, consuming constant stack space regardless of the number of empty blocks (GitHub Advisory, Patch Commit).

Successful exploitation results in a denial-of-service condition limited to availability impact — there is no memory corruption, no data exposure, and no integrity impact. An attacker can crash the decoding thread of any application that processes attacker-controlled LZ4 block streams with stopOnEmptyBlock=false, potentially rendering the decompression service unavailable. The scope is unchanged, meaning only the vulnerable component is affected, and lateral movement or data exfiltration are not possible through this vulnerability alone (GitHub Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires high attack complexity (the attacker must be able to supply a crafted compressed stream to an application using the non-default stopOnEmptyBlock=false configuration), which limits the practical attack surface (GitHub Advisory, Feedly).

1. Identify target: Locate an application that uses lz4-java (Maven artifact at.yawk.lz4:lz4-java ≤ 1.11.3 or org.lz4:lz4-java ≤ 1.8.1) and accepts attacker-controlled compressed data, specifically configured with LZ4BlockInputStream.newBuilder().withStopOnEmptyBlock(false) or the deprecated LZ4BlockInputStream(InputStream, boolean) constructor.
2. Craft malicious payload: Construct a byte stream consisting of a long sequence of well-formed empty LZ4 blocks (each 21 bytes, containing the LZ4 magic bytes, compression method byte, and zeroed length fields), followed optionally by valid LZ4 data. Approximately 10,000–100,000 empty blocks (210 KB–2.1 MB) are sufficient to trigger the overflow.
3. Deliver payload: Submit the crafted compressed stream to the target application through whatever input channel it exposes (e.g., network API, file upload, message queue).
4. Trigger StackOverflowError: The application's LZ4BlockInputStream.refill() method recursively calls itself once per empty block until the JVM thread stack is exhausted, throwing an uncaught StackOverflowError and crashing the decoding thread, resulting in denial of service (GitHub Advisory, Patch Commit).

• Logs: Java application logs showing java.lang.StackOverflowError originating from net.jpountz.lz4.LZ4BlockInputStream.refill() or LZ4BlockInputStream.readBlock(); thread dump entries showing deep recursive call stacks in the LZ4 decompression path.
• Application Behavior: Sudden termination or unresponsiveness of threads responsible for decompressing LZ4 data; repeated service restarts or worker thread failures in applications processing compressed streams.
• Network: Unusually large or repetitive compressed data submissions (210 KB–2.1 MB payloads consisting of repeated 21-byte patterns) sent to endpoints that accept LZ4-compressed input.

Upgrade lz4-java to version 1.11.4, which fixes the vulnerability by replacing the recursive refill() call with an iterative loop. For applications that cannot upgrade immediately, two workarounds are available: (1) ensure LZ4BlockInputStream uses the default stopOnEmptyBlock=true setting for any untrusted input, or (2) wrap the read loop with a catch (StackOverflowError e) block to prevent unhandled thread termination. The org.lz4:lz4-java artifact (versions ≤ 1.8.1) has no patched release noted; users of that artifact should migrate to at.yawk.lz4:lz4-java 1.11.4 (GitHub Advisory, Release Notes).