CVE-2026-106453.

Disclosure summary

### Summary `LZ4DecompressorWithLength.decompress(byte[], int)` allocates whatever size the 4-byte length header declares, before it reads a single byte of compressed data. A 5-byte input whose header says `0x40000000` makes the JVM commit a gigabyte and can cause heap exhaustion. ### Details `net.jpountz.lz4.LZ4DecompressorWithLength` reads the header and passes it straight on: ```java final int destLen = getDecompressedLength(src, srcOff); return fastDecompressor.decompress(src, srcOff + 4, destLen); ``` and `net.jpountz.lz4.LZ4FastDecompressor` allocates it: ```java public final byte[] decompress(byte[] src, int srcOff, int destLen) { final byte[] decompressed = new byte[destLen]; decompress(src, srcOff, decompressed, 0, destLen); return decompressed; } ``` `getDecompressedLength` performs no validation: no comparison against `src.length`, no ceiling, no rejection of negatives. `LZ4SafeDecompressor.decompress(byte[], int, int, int)` has the same shape with `maxDestLen`. The sibling overload that callers pass their own buffer to, `decompress(src, srcOff, dest, destOff, destLen)`, is fine, because there `destLen` is chosen by the caller rather than by the input. The bug is specifi

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