CVE-2026-106453: 
Java vulnerability analysis and mitigation

CVE-2026-106453 is a Denial of Service vulnerability in yawkat's LZ4 Java library (lz4-java) caused by unvalidated memory allocation based on an attacker-controlled decompressed-length header. Prior to version 1.11.2, LZ4DecompressorWithLength reads a four-byte length header from compressed input and allocates the declared output buffer size without any validation, allowing a five-byte malicious input to trigger up to approximately 2 GiB of JVM heap allocation and cause an OutOfMemoryError. Affected Maven packages include at.yawk.lz4:lz4-java (versions ≤ 1.11.1) and org.lz4:lz4-java (versions ≤ 1.8.1). The vulnerability was published 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 LZ4DecompressorWithLength, the method getDecompressedLength() reads a raw 32-bit integer from the first four bytes of the compressed input and passes it directly to LZ4FastDecompressor.decompress() or LZ4SafeDecompressor.decompress(), which allocate a byte[] of that declared size — with no comparison against the actual compressed data length, no ceiling, and no rejection of negative or oversized values. The vulnerable code path is: final int destLen = getDecompressedLength(src, srcOff); return fastDecompressor.decompress(src, srcOff + 4, destLen); — where destLen is fully attacker-controlled. Only the convenience overloads that allocate their own output buffer are affected; overloads that write to a caller-provided destination buffer are not vulnerable because the caller controls the destination size (GitHub Advisory, Patch Commit).

Successful exploitation results in JVM heap exhaustion, causing an OutOfMemoryError and denial of service for any application that decompresses attacker-supplied LZ4 frames through the with-length convenience API. A single five-byte crafted message can trigger up to approximately 2 GiB of heap allocation per call; a small number of concurrent such requests is sufficient to exhaust the heap of a typical JVM service. There is no impact on confidentiality or integrity — only availability is affected (GitHub Advisory, Red Hat Bugzilla).

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 EPSS score is 0.0, reflecting a currently low probability of exploitation in the wild. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. However, the attack requires no authentication, no privileges, and no user interaction — only the ability to send bytes to a service that uses the vulnerable decompression API — making it trivially exploitable if a public-facing service is affected.

1. Reconnaissance: Identify services that accept LZ4-compressed data over the network and use the lz4-java library (Maven artifact at.yawk.lz4:lz4-java ≤ 1.11.1 or org.lz4:lz4-java ≤ 1.8.1) with the LZ4DecompressorWithLength convenience API.
2. Craft malicious payload: Construct a five-byte input where the first four bytes encode a large decompressed length (e.g., 0x40 0x00 0x00 0x00 for 1 GiB, or 0x00 0x00 0x00 0x40 in little-endian for ~1 GiB), followed by a single byte representing an empty LZ4 block (0x00).
3. Send payload: Transmit the crafted five-byte message to the target service endpoint that passes the data to LZ4DecompressorWithLength.decompress(byte[], int) or similar convenience overloads.
4. Trigger heap exhaustion: The library reads the declared length from the header and allocates a byte[] of that size before reading any compressed data, causing the JVM to commit up to ~2 GiB of heap memory per request.
5. Achieve denial of service: Send a small number of concurrent such requests to exhaust the JVM heap, resulting in OutOfMemoryError and service crash or severe degradation (GitHub Advisory, Patch Commit).

• Network: Repeated small (5-byte) requests to service endpoints that accept LZ4-compressed data; unusual spikes in inbound traffic volume to decompression-handling endpoints.
• Logs: Java application logs showing OutOfMemoryError or LZ4Exception: Invalid decompressed length (on patched versions); JVM garbage collection logs indicating sudden large heap allocation events.
• Process: JVM process exhibiting sudden, extreme memory consumption (approaching or exceeding configured -Xmx heap limit) without a corresponding increase in legitimate workload; service crashes or restarts correlated with receipt of small compressed payloads.

Upgrade lz4-java to version 1.11.2 or later, which introduces a configurable maxDecompressedLength (defaulting to 64 MiB) and validates the declared decompressed length against both the configured maximum and the actual compressed data size before allocating memory (GitHub Release, Patch Commit). If immediate patching is not possible, refactor code to use only the overloads that write to a caller-provided destination buffer (e.g., decompress(src, srcOff, dest, destOff, destLen)), as these are not affected because the caller controls the destination size. Additionally, implement JVM heap monitoring and alerting to detect and respond to out-of-memory conditions as a compensating control (GitHub Advisory).

Red Hat has tracked this vulnerability via their security response process (Bugzilla Bug 2547132) and assigned it medium severity, with 33 users on the CC list indicating broad internal interest across Red Hat product teams (Red Hat Bugzilla). The vulnerability was credited to reporter arpitjain099 in the GitHub Security Advisory (GitHub Advisory). No significant broader media coverage or notable public researcher commentary has been identified at this time.