CVE-2026-106449 CVE-2026-106450 CVE-2026-106451 CVE-2026-106452 CVE-2026-106453 at.yawk.lz4:lz4-java: Decompression DoS and native-library hijack via shared tmpdir (1.11.1 -> 1.11.4)

[dependabot]

Bumps at.yawk.lz4:lz4-java from 1.11.1 to 1.11.4 in openam-cassandra/pom.xml (dependencyManagement), clearing Dependabot alerts #354–#358: five advisories published against the 1.11.x line on 2026-10-07, two fixed in 1.11.2 and three in 1.11.4. This follows #1085, which took the same dependency from 1.10.1 to 1.11.1 for CVE-2026-59949.

Advisories

CVE-2026-106453 / GHSA-6cx8-rjf8-pr8g (fixed in 1.11.2) — Memory allocation with excessive size value (CWE-789) in LZ4DecompressorWithLength.decompress(byte[], int): it allocates whatever the 4-byte length header declares before reading any compressed data, so a 5-byte input asking for 0x40000000 commits 1 GiB and can exhaust the heap; LZ4SafeDecompressor.decompress(byte[], int, int, int) has the same shape. 1.11.2 validates length-prefixed sizes against a 64 MiB default limit and a decompression-ratio check; 1.11.3 makes the default configurable through the net.jpountz.lz4.LZ4DecompressorWithLength.maxDecompressedLength system property.

CVE-2026-106452 / GHSA-4v53-57pg-c464 (fixed in 1.11.2) — Memory allocation with excessive size value (CWE-789) in LZ4BlockInputStream.refill(): the compressed-input buffer grows to the attacker-controlled compressedLen of the legacy LZ4Block header before any payload is read, so a header-only input triggers a near-2 GiB allocation. 1.11.2 rejects LZ4-method blocks whose compressed length exceeds the uncompressed one (a canonical writer emits those as RAW); the new acceptOversizedBlocks flag restores the old behaviour together with the DoS vector.

CVE-2026-106450 / GHSA-gm45-99xc-r7wv (fixed in 1.11.4) — Allocation of resources without limits (CWE-770) in LZ4FrameInputStream.readHeader(): every frame header allocates two fresh buffers of the frame's maximum block size (up to 4 MiB each), and concatenated frames are read by default, so an 11-byte empty frame forces ~8 MiB of zeroed allocation — about 8 s of CPU for 110 KB of input. 1.11.4 allocates block buffers only when a block needs them and reuses them across frames. readSingleFrame = true was never affected.

CVE-2026-106449 / GHSA-343h-94h5-c4wr (fixed in 1.11.4) — Uncontrolled recursion (CWE-674) in LZ4BlockInputStream.refill() with stopOnEmptyBlock = false: each 21-byte empty block recurses once, so 10,000–100,000 of them throw StackOverflowError out of read() / skip(), which IOException handlers do not catch. 1.11.4 skips empty blocks in a loop. The default stopOnEmptyBlock = true was never affected.

CVE-2026-106451 / GHSA-mcr4-qmvw-px4g (fixed in 1.11.4) — Insecure temporary file / TOCTOU race (CWE-377, CWE-367) in net.jpountz.util.Native.load(): when no system liblz4-java is found, the bundled JNI library is extracted to java.io.tmpdir under a predictable name (the random .lck name minus its suffix) that is opened without exclusive creation. A local user who shares that directory and wins the race can plant the file and have their code loaded into the victim JVM (with fs.protected_regular >= 1 only a fallback to the pure-Java implementation, i.e. no code execution). 1.11.4 extracts straight into a file from File.createTempFile and drops the .lck files. Introduced upstream in lz4-java 1.7.0.

	Severity	Affected	Fixed in
GHSA-6cx8-rjf8-pr8g	Medium — CVSS 3.1 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L)	<= 1.11.1	1.11.2
GHSA-4v53-57pg-c464	Medium — CVSS 3.1 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L)	<= 1.11.1	1.11.2
GHSA-gm45-99xc-r7wv	Medium — CVSS 3.1 5.3 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L)	<= 1.11.3	1.11.4
GHSA-343h-94h5-c4wr	Low — CVSS 3.1 3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L)	<= 1.11.3	1.11.4
GHSA-mcr4-qmvw-px4g	High — no CVSS vector published	<= 1.11.3	1.11.4

Four are availability-only; GHSA-mcr4-qmvw-px4g is a local code-execution race that needs a shared temporary directory, a permissive host and a won race.

Impact on OpenAM

lz4-java ships in the WAR (WEB-INF/lib/lz4-java-1.11.1.jar, via openam-cassandra-datastore, which openam-server-only depends on) next to java-driver-core 4.19.2. No OpenAM source imports net.jpountz; the only consumer is the Cassandra driver's Lz4Compressor, which calls LZ4Factory.fastestInstance() and the fastCompressor() / fastDecompressor() ByteBuffer overloads with caller-supplied lengths — not LZ4BlockInputStream, LZ4FrameInputStream or LZ4DecompressorWithLength. So the four DoS advisories are not reachable from OpenAM.

The driver creates Lz4Compressor only when advanced.protocol.compression = lz4 is set. OpenAM's openam-cassandra-datastore/src/main/resources/application.conf does not set it, and the driver's reference.conf leaves it absent (frames uncompressed), so by default the native library is never loaded and CVE-2026-106451 is not reachable either. A deployment that turns LZ4 protocol compression on through its own driver configuration loads the JNI library through Native.load(); on 1.11.1 that is exposed to CVE-2026-106451 when java.io.tmpdir is shared with other local users (e.g. the default world-writable /tmp without PrivateTmp). The bump closes that.

openam-cassandra-embedded (Cassandra server, cassandra-all) also takes its lz4-java version from this dependencyManagement entry, but is a test-scoped dependency of the datastore and CTS modules and is not in the WAR.

Change

openam-cassandra/pom.xml, dependencyManagement: at.yawk.lz4:lz4-java 1.11.1 → 1.11.4. It governs openam-cassandra-datastore and openam-cassandra-embedded. No code change.

Behaviour changes in the new range, none of which touches the driver's code path:

• 1.11.2: LZ4DecompressorWithLength rejects declared sizes above 64 MiB (configurable since 1.11.3), and LZ4BlockInputStream rejects oversized LZ4-method blocks unless acceptOversizedBlocks is set.
• 1.11.4: stale liblz4-java-* temporary files (including old .lck files) older than one hour are removed at startup.

References

• GHSA-6cx8-rjf8-pr8g
• GHSA-4v53-57pg-c464
• GHSA-gm45-99xc-r7wv
• GHSA-343h-94h5-c4wr
• GHSA-mcr4-qmvw-px4g
• https://nvd.nist.gov/vuln/detail/CVE-2026-106453
• https://nvd.nist.gov/vuln/detail/CVE-2026-106452
• https://nvd.nist.gov/vuln/detail/CVE-2026-106450
• https://nvd.nist.gov/vuln/detail/CVE-2026-106449
• https://nvd.nist.gov/vuln/detail/CVE-2026-106451
• yawkat/lz4-java@v1.11.1...v1.11.4