Most recent entries from all

fkie_cve-2026-106453

2026-10-09T10:08:19.114236+00:00

yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, LZ4DecompressorWithLength uses getDecompressedLength to trust the four-byte decompressed-length header before validating the compressed input, allowing a five-byte attacker-supplied input whose header declares a large output size to request up to approximately 2 GiB and exhaust the JVM heap. Convenience overloads backed by LZ4FastDecompressor or LZ4SafeDecompressor allocate the untrusted size, while overloads that write to a caller-provided destination buffer are not affected because the caller controls the destination size. This issue is fixed in version 1.11.2.

GHSA-6cx8-rjf8-pr8g — yawkat LZ4 Java: LZ4DecompressorWithLength allocates the unvalidated size from the 4-byte length header, so a 5-byte in…

2026-10-09T10:08:19.114303+00:00

Affected: Maven: at.yawk.lz4:lz4-java, Maven: org.lz4:lz4-java

### 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 specific to the convenience overloads that take the size from the header, and that difference is the whole finding.

### Impact

Any application that decompresses attacker-supplied LZ4 frames through the with-length convenience API can be made to allocate up to 2 GiB per call from a 5-byte m…

UBUNTU-CVE-2026-106453

2026-10-09T10:08:19.114370+00:00

Affected: Ubuntu:20.04:LTS: lz4-java, Ubuntu:22.04:LTS: lz4-java, Ubuntu:24.04:LTS: lz4-java, Ubuntu:26.04:LTS: lz4-java

(yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, LZ ...)