CVE-2026-59949: 
Java vulnerability analysis and mitigation

CVE-2026-59949 is a vulnerability in the JNI-based XXHash implementations of lz4-java that allows callers to crash the JVM by passing invalid byte array references or out-of-bounds offset/length arguments to native XXHash methods. It affects at.yawk.lz4:lz4-java versions ≤ 1.11.0 (patched in 1.11.1) and org.lz4:lz4-java versions ≤ 1.8.1 (no patch available for the upstream package at time of disclosure). Java-based XXHash implementations are not affected. The vulnerability was first published on July 6, 2026, and added to the GitHub Advisory Database on July 24, 2026. It carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory).

The root cause is insufficient input validation (CWE-125: Out-of-bounds Read; CWE-476: NULL Pointer Dereference) in the JNI bridge layer of lz4-java's XXHash implementations. Two distinct failure modes exist: (1) passing a null byte array with len == 0 bypasses the SafeUtils.checkRange guard (which skipped validation when len == 0) and reaches GetPrimitiveArrayCritical in native code, causing a fatal JVM crash; (2) passing an oversized len (e.g., Integer.MAX_VALUE) to the streaming APIs causes native XXHash code to read far beyond the Java array boundary, crashing the JVM and potentially exposing in-process memory. The streaming implementations (StreamingXXHash32JNI, StreamingXXHash64JNI) performed no validation at all before the fix, while the non-streaming implementations had an incomplete guard. Exploitation requires attacker control over the byte array object itself or the off/len parameters — not merely the array contents (GitHub Advisory, Fix Commit).

The primary impact is denial of service through fatal JVM termination, which would bring down any Java application relying on the JNI-backed XXHash APIs if an attacker can influence the array reference or range parameters. A secondary, limited confidentiality risk exists: when an oversized len is passed to the streaming APIs, native code may read memory beyond the Java array boundary before the process crashes, potentially exposing in-process memory contents to the native routine. Integrity is not impacted. The scope is limited to the affected JVM process; lateral movement is not a direct consequence of this vulnerability (GitHub Advisory).

1. Identify a vulnerable application: Locate a Java application using at.yawk.lz4:lz4-java ≤ 1.11.0 or org.lz4:lz4-java ≤ 1.8.1 that exposes an API endpoint or input path where attacker-supplied data influences the byte array object, offset, or length passed to a JNI-backed XXHash method.
2. Determine the attack surface: Confirm that the application calls XXHashFactory.nativeInstance() (not safeInstance()) and that attacker input can reach the buf, off, or len parameters of hash32(), hash64(), newStreamingHash32().update(), or newStreamingHash64().update().
3. Trigger NULL dereference (crash via null array): Craft input that causes the application to invoke hash(null, 0, 0, seed) or update(null, 0, 0). The len == 0 check bypass allows the null reference to reach GetPrimitiveArrayCritical in native code, causing a fatal JVM crash.
4. Trigger out-of-bounds read (crash via oversized length): Alternatively, craft input that causes the application to call update(new byte[16], 0, Integer.MAX_VALUE) on a streaming hash instance. The missing range validation in the streaming JNI implementation allows native code to read far beyond the array, crashing the JVM.
5. Achieve denial of service: Either path results in a fatal, unrecoverable JVM crash, taking down the target application (GitHub Advisory, Fix Commit).

• Logs: Sudden JVM crash logs (e.g., hs_err_pid*.log files) referencing GetPrimitiveArrayCritical or native XXHash methods (XXH32_update, XXH64_update) in the crash stack trace.
• Process: Unexpected termination of Java application processes without a Java-level exception or graceful shutdown; crash dump files generated in the application working directory.
• Application Logs: Absence of normal shutdown log entries immediately preceding a process exit, combined with OS-level signals (e.g., SIGSEGV, SIGBUS) recorded in system logs.

Upgrade at.yawk.lz4:lz4-java to version 1.11.1, which adds proper null and range validation before all JNI XXHash calls without requiring changes to user code (lz4-java Release). Note that org.lz4:lz4-java ≤ 1.8.1 has no patched version available at this time. If upgrading is not immediately possible, switch to XXHashFactory.safeInstance() instead of nativeInstance() to use the pure-Java XXHash implementation, which is not affected by this vulnerability. As an additional defense-in-depth measure, validate that byte arrays are non-null and that off and len describe a range fully within the array before passing them to any JNI-backed XXHash API (GitHub Advisory).