CVE-2026-106452.

Disclosure summary

### Summary `LZ4BlockInputStream` grows its compressed-input buffer to the attacker-controlled `compressedLen` value from the legacy `LZ4Block` stream header before reading any payload bytes. A header-only input can therefore trigger a near-2 GiB allocation and exhaust the JVM heap. ### Details In `net.jpountz.lz4.LZ4BlockInputStream`, `refill()` validates that `compressedLen` is nonnegative but does not cap it before allocation: ```java case COMPRESSION_METHOD_LZ4: if (compressedBuffer.length < compressedLen) { compressedBuffer = new byte[Math.max(compressedLen, compressedBuffer.length * 3 / 2)]; } readFully(compressedBuffer, compressedLen); ``` The paired `LZ4BlockOutputStream` never emits such a block. If compression is not smaller than the original block, it writes the block as RAW: ```java if (compressedLength >= o) { compressMethod = COMPRESSION_METHOD_RAW; compressedLength = o; } else { compressMethod = COMPRESSION_METHOD_LZ4; } ``` Existing readers generally accept noncanonical LZ4-method blocks where `compressedLen >= originalLen`, but no canonical writer found produces them. ### Impact Applications that pass attacker-controlled legacy `LZ4Block` streams to `LZ4BlockInputS

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-07T12:17:50-04:00
MODIFIED 2026-10-07T12:17:51-04:00
INGESTED 2026-10-08T12:05:11-04:00