CVE-2026-106449.

Disclosure summary

### Summary When `LZ4BlockInputStream` is configured with `stopOnEmptyBlock = false` (the mode for reading concatenated block streams), it handles each empty block by calling `refill()` recursively. A long run of empty blocks exhausts the thread stack and throws `StackOverflowError` out of `read()` or `skip()`. ### Details In `net.jpountz.lz4.LZ4BlockInputStream.refill()`: ```java if (originalLen == 0 && compressedLen == 0) { if (check != 0) { throw new IOException("Stream is corrupted"); } if (!stopOnEmptyBlock) { refill(); } else { finished = true; } return; } ``` Each well-formed empty block is 21 bytes and adds one stack frame, with no limit on nesting depth. In local testing, around 10,000 to 100,000 consecutive empty blocks (about 210 KB to 2.1 MB, depending on JIT state and thread stack size) threw `StackOverflowError`. `StackOverflowError` is an `Error`, not an `IOException`, so callers that only handle I/O errors for corrupt input don't catch it. ### Impact Applications that decode attacker-controlled `LZ4Block` streams with `LZ4BlockInputStream.newBuilder().withStopOnEmptyBlock(false)` or the deprecated `LZ4BlockInputStream(InputStream, boolean)` constructor can have the

Source-specific records & product guidance

Sources retain their own attribution and scoring. Follow the original record to confirm affected versions, fixed releases, and configuration conditions.

Original records & references

• NIST NVD record
• CVE Program record
• github.com — Reviewed advisory

PUBLISHED 2026-10-07T16:35:46-04:00
MODIFIED 2026-10-07T16:35:46-04:00
INGESTED 2026-10-08T12:30:39-04:00