Vulnerability in at.yawk.lz4:lz4-java (CVE-2026-106453)
Summary
Vulnerability in at.yawk.lz4:lz4-java (CVE-2026-106453). Risk of unauthorized operations or information disclosure. Exploitable via net.jpountz.lz4.LZ4DecompressorWithLength. Mitigation: upgrade to 1.11.2 or later.
Original description
The description as published by the source.
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:
final int destLen = getDecompressedLength(src, srcOff);
return fastDecompressor.decompress(src, srcOff + 4, destLen);
and net.jpountz.lz4.LZ4FastDecompressor allocates it:
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 me…
Source: NIST National Vulnerability Database NVD GitHub Advisory
Auto-generated summary
Assembled by SecPulse from the source data (CVSS, CWE, affected versions) using templates — no AI involved. Check the original description and references below for exact details.
A vulnerability tracked as CVE-2026-106453 has been found in at.yawk.lz4:lz4-java.
Attackers can target a specific entry point like net.jpountz.lz4.LZ4DecompressorWithLength over the network to misuse the product.
Risk of unauthorized operations or information disclosure. CVSS score: 5.3/10.
What to do: upgrade at.yawk.lz4:lz4-java to 1.11.2 or later.
If unsure, ask your IT team or search "at.yawk.lz4:lz4-java CVE-2026-106453" on the vendor's site.
CVE-2026-106453 (at.yawk.lz4:lz4-java) — CWE-789 / CVSS v3 5.3
Attack vector: remote (network-reachable) / unauthenticated / no user interaction
Attack surface: net.jpountz.lz4.LZ4DecompressorWithLength / net.jpountz.lz4.LZ4FastDecompressor / getDecompressedLength / src.length
Patched: 1.11.2 — apply immediately
Plan: 1) Audit SBOM/dependencies, 2) Stage→prod upgrade, 3) Add WAF/proxy monitoring on affected endpoints, 4) Hunt IOCs in logs.
Refs: see the GHSA / vendor advisory / patched release linked on this page.
A vulnerability (CWE-789) exists in at.yawk.lz4:lz4-java. Attackers reach the vulnerable code path via net.jpountz.lz4.LZ4DecompressorWithLength without authentication.
Check the vendor advisory for the affected versions of at.yawk.lz4:lz4-java. Attack surface: net.jpountz.lz4.LZ4DecompressorWithLength / net.jpountz.lz4.LZ4FastDecompressor / getDecompressedLength / src.length.
Severity: Medium (CVSS 5.3/10). Risk of unauthorized operations or information disclosure.
Update to 1.11.2.
Until the patch is applied: disable the affected feature, apply WAF rules, or restrict access via network ACLs.
Search webserver/proxy logs for unusual request patterns matching this CVE's known IOCs. Audit SBOM/dependencies to find affected services.
Response actions
Concrete steps and command examples for SOC/SRE teams to execute in order
-
1Identify exposure identify
Audit SBOM/dependencies for affected components.資産台帳・SBOM・依存マニフェストで at.yawk.lz4:lz4-java を使っているサービスとバージョンを洗い出す。
-
2Apply patch patch
Upgrade at.yawk.lz4:lz4-java to 1.11.2ステージング環境で 1.11.2 に上げて回帰テスト → 本番反映。回帰テストはアプリの主要ハッピーパスを含めること。
-
3Post-deployment verification verify
Confirm patched version is live in productionパッチ適用後、ステージングで PoC または同等の悪用パターンを再現して脆弱性が閉じたことを確認。本番ではアクセスログ・WAF でアラート再発が無いか継続監視。