CVE-2026-59949 in lz4-java
Summary
by MITRE • 08/18/2026
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.1, JNI-backed XXHash implementations fail to validate the byte array object and the off and len arguments in XXHashFactory.nativeInstance().hash32().hash(), XXHashFactory.nativeInstance().hash64().hash(), XXHashFactory.nativeInstance().newStreamingHash32().update(), and XXHashFactory.nativeInstance().newStreamingHash64().update(), allowing null arrays or oversized ranges to reach native code, read outside the Java array, and fatally terminate the JVM. This issue is fixed in version 1.11.1.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in yawkat LZ4 Java prior to version 1.11.1 represents a critical failure in input validation within the native interface layer of the library, specifically affecting XXHash implementations that rely on JNI-backed methods for performance optimization. The core technical flaw lies in the insufficient boundary checking and null pointer verification performed by several key functions including hash32().hash(), hash64().hash(), newStreamingHash32().update(), and newStreamingHash64().update() within the XXHashFactory class. When these native methods are invoked, they accept byte array objects along with offset and length parameters directly from Java code without rigorous validation to ensure that the specified range falls entirely within the bounds of the provided array or that the array itself is not null. This lack of defensive programming allows malicious or malformed inputs to bypass standard safety checks inherent in managed languages like Java, effectively creating a bridge through which unsafe operations can be executed at the native level.
The operational impact of this vulnerability is severe due to its potential for causing denial-of-service conditions and potentially leading to further exploitation vectors depending on the surrounding application context. By allowing null arrays or oversized ranges to reach the native code layer, an attacker can trigger out-of-bounds memory reads when the JNI wrapper attempts to access data at invalid addresses relative to the array base pointer. This typically results in a segmentation fault or similar critical error that causes the Java Virtual Machine to terminate abruptly and ungracefully. In production environments where high availability is required, such as real-time analytics pipelines or compression-heavy microservices, this can lead to significant service disruptions. Furthermore, while the primary reported impact is fatal termination, out-of-bounds reads in native code can sometimes leak sensitive information from adjacent memory locations if not properly isolated by the operating system's memory protection mechanisms, although the immediate and most certain consequence remains application crash.
From a classification perspective, this vulnerability aligns with CWE-125 Out-of-bounds Read, as it involves accessing memory beyond the intended buffer boundaries due to unchecked input parameters. It also relates closely to CWE-476 NULL Pointer Dereference in cases where null arrays are passed without validation. In terms of adversary tactics and techniques, this flaw could be leveraged within an ATT&CK framework context under T1498 Network Denial of Service or potentially as part of a broader exploitation chain if the application logic relies on predictable crash behavior for control flow manipulation, though its primary utility lies in causing service disruption. The vulnerability highlights the risks associated with JNI integration where trust boundaries between managed and unmanaged code are not strictly enforced by default library implementations.
To mitigate this risk, organizations utilizing yawkat LZ4 Java must upgrade to version 1.11.1 or later immediately, as this release includes comprehensive input validation checks that verify array integrity and parameter bounds before passing data to native methods. For applications unable to update promptly due to dependency constraints, implementing wrapper classes that perform explicit null checking and range verification prior to invoking the affected XXHash functions can serve as a temporary defensive measure. Additionally, developers should audit other JNI interfaces within their codebase for similar patterns of unchecked input propagation to prevent analogous vulnerabilities in related components. Regular security testing including fuzzing of native interface boundaries is recommended to detect such issues early in the development lifecycle and ensure robust handling of edge cases involving array manipulation and memory access.