CVE-2026-87823 in zstd-jni
Summary
by MITRE • 09/09/2026
zstd-jni before 1.5.7-14 performs 32-bit signed bounds checks on three direct-ByteBuffer frame-size native methods, allowing out-of-bounds memory reads via negative or overflowing offsets. Attackers can supply negative offset values near Integer.MIN_VALUE to read unmapped memory, causing JVM termination or extracting arbitrary frame size data from unintended memory locations.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in zstd-jni versions prior to 1.5.7-14 represents a critical integer overflow and bounds checking failure within the native bindings for the Zstandard compression library. This flaw specifically affects three direct ByteBuffer methods responsible for handling frame sizes, where the implementation relies on 32-bit signed integers for offset calculations without adequate validation against negative values or arithmetic overflows. In Java Native Interface (JNI) programming, when a Java integer is passed to a native C or C++ method, it retains its signed nature unless explicitly cast or validated by the developer. The zstd-jni library failed to account for the fact that a large unsigned value interpreted as a negative signed integer could bypass standard upper-bound checks, leading to invalid memory access patterns during decompression operations.
From a technical perspective, the core issue lies in the lack of rigorous input sanitization before performing pointer arithmetic or array indexing based on user-supplied offsets. When an attacker provides a negative offset close to Integer.MIN_VALUE, such as -2147483648, the resulting memory address calculation wraps around due to two's complement representation rules. This causes the native code to access memory locations far outside the intended buffer boundaries. Instead of rejecting the invalid input with an appropriate exception or error code, the library proceeds to read from these unmapped or unintended memory regions. This behavior violates fundamental principles of secure coding regarding boundary validation and type safety in mixed-language environments involving Java and native libraries.
The operational impact of this vulnerability is severe, primarily manifesting as a denial-of-service condition through JVM termination. When the process attempts to access unmapped memory pages, the operating system typically sends a segmentation fault signal, causing the Java Virtual Machine to crash abruptly. This disrupts any service relying on zstd-jni for data processing, leading to availability loss. Furthermore, in scenarios where the underlying OS or runtime environment allows partial information disclosure before crashing, there is a risk of extracting arbitrary frame size data from unintended memory locations. While the primary vector described emphasizes denial-of-service, the potential for reading sensitive data residing adjacent to the buffer could lead to confidentiality breaches if not properly mitigated by surrounding security controls such as address space layout randomization or sandboxing mechanisms.
This vulnerability aligns with Common Weakness Enumeration (CWE) categories including CWE-190 Integer Overflow or Wraparound and CWE-787 Out-of-bounds Read. The exploitation technique involves manipulating input values to bypass logical checks, which is characteristic of improper validation flaws often found in native code interfaces. In the context of the MITRE ATT&CK framework, this vulnerability facilitates initial access disruption rather than direct data exfiltration or privilege escalation, placing it within tactics related to Impact and potentially Execution if combined with other vulnerabilities. The attack vector requires remote interaction if the service is exposed over a network, making it relevant for web applications or microservices that process compressed payloads from untrusted sources.
To mitigate this risk, organizations must immediately upgrade zstd-jni to version 1.5.7-14 or later, where these bounds checks have been corrected to properly handle signed integer limitations and validate input ranges before native execution. For systems unable to update promptly, implementing strict input validation at the Java layer is essential. Developers should ensure that all offsets passed to JNI methods are checked for negativity and reasonable magnitude limits before invocation. Additionally, deploying runtime application self-protection (RASP) solutions or using JVM flags like -XX:+ShowMessageBoxOnError can help in detecting such crashes during testing phases. Regular security audits focusing on native code integration points and fuzzing tests targeting edge cases in integer handling are recommended to prevent similar vulnerabilities in other components of the software stack.