Answer in brief
CVE-2026-106452 records a Medium severity (CVSS 5.3) vulnerability in yawkat LZ4 Java: LZ4BlockInputStream allocates an unvalidated compressed length from the stream header. The current sources do not mark it as known exploited. The current feed maps yawkat/lz4-java (generic). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 5.3. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps yawkat/lz4-java (generic). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| yawkat/lz4-javageneric | <1.11.2 | 1.11.2 |
Published upstream
Oct 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 6, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Oct 6, 2026
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.2, net.jpountz.lz4.LZ4BlockInputStream refill() validates that the compressedLen field in a legacy LZ4Block header is nonnegative but allocates a compressed-input buffer of that attacker-controlled size before reading payload data, allowing a header-only stream to request a near-2 GiB allocation and exhaust the JVM heap. Canonical writers emit raw blocks when compression is not smaller than the original block, but vulnerable readers accept non-canonical oversized compressed blocks. This issue is fixed in version 1.11.2.
Quoted source text, attributed separately from HOL analysis.