CVE-2026-106452: 
Java vulnerability analysis and mitigation

CVE-2026-106452 is a Denial of Service vulnerability in yawkat's lz4-java library caused by unvalidated memory allocation based on an attacker-controlled field in the legacy LZ4Block stream header. The LZ4BlockInputStream.refill() method checks that the compressedLen field is nonnegative but allocates a buffer of that size before reading any payload data, allowing a crafted header-only stream to trigger a near-2 GiB heap allocation and exhaust the JVM. Affected versions are at.yawk.lz4:lz4-java ≤ 1.11.1 and org.lz4:lz4-java ≤ 1.8.1 (no patch available for the latter). The vulnerability was disclosed on October 6, 2026, and carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified as CWE-789 (Memory Allocation with Excessive Size Value) and CWE-770 (Allocation of Resources Without Limits or Throttling). In net.jpountz.lz4.LZ4BlockInputStream, the refill() method validates that compressedLen is nonnegative but immediately allocates new byte[Math.max(compressedLen, compressedBuffer.length * 3 / 2)] before reading any payload bytes — meaning a crafted header with a near-Integer.MAX_VALUE value can force a ~2 GiB allocation with no actual data required. The paired LZ4BlockOutputStream never produces such blocks (it emits RAW blocks when compressed size ≥ original size), but the reader accepts these non-canonical LZ4-method blocks, creating an asymmetry exploitable by any attacker who can supply a crafted stream. The fix in 1.11.2 adds a validation check rejecting LZ4 blocks where compressedLen >= originalLen unless the new acceptOversizedBlocks flag is explicitly enabled (GitHub Advisory, Patch Commit).

Successful exploitation results in JVM heap exhaustion, causing the affected Java application to crash or become unresponsive — a pure availability impact with no confidentiality or integrity consequences. Any application that passes attacker-controlled data to LZ4BlockInputStream is at risk, including network services, message brokers, or data pipelines that decompress LZ4-encoded input from untrusted sources. Because only a malformed header (no valid payload) is required, the attack is extremely low-cost and can be repeated to sustain a denial-of-service condition (GitHub Advisory).

No public proof-of-concept exploit code has been identified, and there is no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability is unauthenticated and requires no user interaction, making it trivially exploitable against any exposed service that processes untrusted LZ4 block streams. The EPSS score is reported as 0.0, and the vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities catalog. No threat actor attribution has been identified.

1. Identify a target: Locate a Java application or network service that uses org.lz4:lz4-java or at.yawk.lz4:lz4-java versions ≤ 1.11.1 and accepts LZ4-compressed data from untrusted network sources (e.g., a message broker, REST API, or data ingestion service).
2. Craft a malicious LZ4 block header: Construct a legacy LZ4Block stream with the magic bytes (LZ4Block / 76 5A 34 42 6C 6F 63 6B 20) followed by the compression method byte for LZ4 (0x20), then set compressedLen to a large value near Integer.MAX_VALUE (e.g., 0x7FFFFFFF) and any valid originalLen smaller than compressedLen.
3. Send the header-only stream: Transmit the crafted header to the target service without any payload bytes. The refill() method will attempt to allocate a buffer of the specified size before reading data.
4. Trigger heap exhaustion: The JVM attempts to allocate ~2 GiB on the heap; if insufficient memory is available, an OutOfMemoryError is thrown, crashing the service or causing severe degradation. Repeating this request can sustain the denial-of-service condition (GitHub Advisory, Patch Commit).

• Network: Repeated short-lived connections to the service delivering minimal data (header-only payloads of ~13–21 bytes) with no subsequent payload; unusual spikes in connection rate from a single source IP targeting LZ4-processing endpoints.
• Logs: Java application logs showing java.lang.OutOfMemoryError: Java heap space or IOException: Stream is corrupted (on patched versions) correlated with incoming network requests; GC logs showing sudden full GC events or heap exhaustion.
• Process: JVM process exhibiting sudden memory spikes to near-maximum heap capacity followed by crash or restart; application health checks failing intermittently under low network load.

Upgrade at.yawk.lz4:lz4-java to version 1.11.2 or later, which rejects LZ4 blocks where compressedLen >= originalLen by default (GitHub Release). Note that org.lz4:lz4-java ≤ 1.8.1 has no patched version available; users of this artifact should migrate to at.yawk.lz4:lz4-java 1.11.2. As an interim workaround for systems that cannot upgrade immediately, restrict network access to services that process untrusted LZ4-compressed data and validate or sanitize compressedLen values at the application layer. Do not enable the acceptOversizedBlocks flag introduced in 1.11.2 unless inputs are fully trusted, as it reintroduces the DoS vector (GitHub Advisory).

Red Hat has tracked this vulnerability via their security response process (Bugzilla bug 2547136) with medium priority and severity, indicating downstream impact assessment is ongoing for Red Hat products that bundle lz4-java (Red Hat Bugzilla). The vulnerability was self-reported by the library maintainer (yawkat) and fixed promptly in the same release (v1.11.2) that addressed a companion CVE (CVE-2026-106453), reflecting responsible disclosure practices. No significant broader media coverage or notable researcher commentary has been identified beyond standard vulnerability database entries.