CVE-2026-59949: LZ4 Java Buffer Overflow Vulnerability

CVE-2026-59949 Overview

CVE-2026-59949 affects yawkat LZ4 Java, a library that provides LZ4 compression and XXHash utilities for Java applications. The Java Native Interface (JNI) backed XXHash implementations fail to validate input arguments before passing them to native code. Attackers can supply null byte arrays or oversized offset and length ranges to the hash32().hash(), hash64().hash(), newStreamingHash32().update(), and newStreamingHash64().update() methods exposed by XXHashFactory.nativeInstance(). The native code then reads outside the Java array bounds and fatally terminates the Java Virtual Machine (JVM). The vulnerability is tracked under [CWE-476] Null Pointer Dereference and is fixed in version 1.11.1.

Critical Impact
Unvalidated inputs reaching JNI-backed hash routines crash the JVM, producing a denial of service against services that process attacker-controlled data through LZ4 Java's native XXHash paths.

Affected Products

yawkat LZ4 Java versions prior to 1.11.1
Applications using XXHashFactory.nativeInstance() for hashing untrusted input
Java services embedding the native LZ4 Java JNI bindings

Discovery Timeline

2026-08-18 - CVE-2026-59949 published to the National Vulnerability Database (NVD)
2026-08-18 - Last updated in NVD database

Technical Details for CVE-2026-59949

Vulnerability Analysis

The defect lies in the argument-checking helpers used by the JNI-backed XXHash routines. The pre-patch checkRange implementations in SafeUtils and ByteBufferUtils only inspected the buffer when len > 0. When callers passed len == 0 with a null array, or when they passed an offset and length combination that overran the buffer, the checks were skipped or evaluated incorrectly. Execution then reached the native XXHash code, which dereferenced the null pointer or read past the allocated Java array boundary.

Root Cause

The root cause is missing null and bounds validation on the boundary between Java and native code. Because the native XXHash entry points do not repeat the bounds checks that Java callers are expected to perform, any unchecked null reference or out-of-range offset propagates directly into memory reads outside the Java heap allocation. The consequence is a segmentation fault that terminates the JVM rather than a controlled NullPointerException or ArrayIndexOutOfBoundsException.

Attack Vector

An attacker who can influence the byte array, offset, or length arguments passed to XXHashFactory.nativeInstance().hash32().hash() or the streaming update methods can trigger the crash. Exposure is highest in servers that hash attacker-supplied payloads (for example, deduplication services, content-addressed stores, or protocol handlers that use LZ4 Java's native XXHash for integrity checks). Exploitation does not require authentication but does depend on reaching a code path that forwards untrusted values into the vulnerable API.

java

// Security patch in src/java/net/jpountz/util/SafeUtils.java
public static void checkRange(byte[] buf, int off, int len) {
    checkLength(len);
-   if (len > 0) {
-     checkRange(buf, off);
-     checkRange(buf, off + len - 1);
+   // buf.length intentionally performs the null check even when len is 0.
+   if (off < 0 || off > buf.length - len) {
+     throw new ArrayIndexOutOfBoundsException(off);
    }
}

Source: GitHub Commit dbd86d0

The patch replaces the conditional bounds check with an unconditional evaluation. Accessing buf.length triggers a NullPointerException when buf is null, and the new inequality catches oversized ranges regardless of len. An equivalent change applies to ByteBufferUtils.checkRange, which now uses buf.capacity() for the same purpose.

Detection Methods for CVE-2026-59949

Indicators of Compromise

Unexpected JVM termination with a fatal error log (hs_err_pid*.log) referencing native frames in net.jpountz XXHash routines.
SIGSEGV crashes in Java processes correlated with inbound requests carrying null or oversized hash input parameters.
Repeated process restarts of services that hash externally supplied byte arrays through LZ4 Java's native instance.

Detection Strategies

Inventory Java applications and dependencies for yawkat LZ4 Java versions earlier than 1.11.1 using software composition analysis.
Search source and bytecode for calls to XXHashFactory.nativeInstance() combined with untrusted byte array inputs.
Correlate JVM crash telemetry with application logs to identify requests that immediately precede fatal errors.

Monitoring Recommendations

Alert on generation of hs_err_pid files on production Java hosts and forward them to a central log store for triage.
Monitor service supervisors (systemd, Kubernetes) for abnormal restart loops of Java workloads that process external data.
Track dependency manifests (Maven, Gradle) in CI pipelines and fail builds that pull in vulnerable lz4-java releases.

How to Mitigate CVE-2026-59949

Immediate Actions Required

Upgrade yawkat LZ4 Java to version 1.11.1 or later across all applications and container images.
Audit code paths that pass untrusted byte arrays, offsets, or lengths into XXHashFactory.nativeInstance() methods.
Rebuild and redeploy downstream artifacts that transitively bundle the vulnerable library.

Patch Information

The fix is available in yawkat LZ4 Java v1.11.1. The corrective changes are in commit dbd86d0, and additional context is provided in the GitHub Security Advisory GHSA-xx22-p4ch-683r.

Workarounds

Switch callers to XXHashFactory.safeInstance() or XXHashFactory.unsafeInstance(), which do not invoke the vulnerable native path.
Add explicit null and bounds validation in application code before invoking the JNI hash methods.
Reject or sanitize external inputs that supply offsets, lengths, or byte arrays used for hashing until the upgrade is deployed.

bash

# Maven dependency update
mvn versions:use-dep-version -Dincludes=org.lz4:lz4-java -DdepVersion=1.11.1 -DforceVersion=true

# Gradle dependency update
./gradlew dependencies --refresh-dependencies
# In build.gradle: implementation 'org.lz4:lz4-java:1.11.1'