CVE-2026-87824 in zstd-jni
Summary
by MITRE • 09/09/2026
zstd-jni before 1.5.7-14 fails to validate the samples buffer capacity in Zstd.trainFromBufferDirect, allowing attackers to read past buffer boundaries by supplying oversized per-sample lengths. Attackers can trigger out-of-bounds memory access by providing crafted sample length arrays that cause the native implementation to walk past the buffer allocation, resulting in JVM termination.
If you want to get the best quality for vulnerability data then you always have to consider 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 input validation failure within the Java Native Interface binding for the Zstandard compression library. Specifically, the flaw resides in the implementation of the trainFromBufferDirect method, which is designed to process sample data for building dictionary models used in lossless compression. The core technical deficiency involves the absence of rigorous boundary checks on the samples buffer capacity relative to the lengths specified by the caller. When an application invokes this native function with a per-sample length array that exceeds the actual allocated memory size of the underlying byte buffer, the JNI layer fails to detect or reject this discrepancy before passing control to the C++ implementation. This lack of validation allows for out-of-bounds read operations where the native code attempts to access memory locations beyond the end of the designated buffer allocation.
From a technical perspective, this issue classifies as an Out-of-Bounds Read vulnerability under Common Weakness Enumeration standards, specifically aligning with CWE-125. The mechanism exploits the trust placed in Java array bounds checking by assuming that native code will respect those limits without explicit verification at the JNI boundary. In reality, once execution transitions to the native layer, standard JVM memory safety protections are bypassed because the pointer arithmetic is performed directly on raw memory addresses derived from the buffer's base address and the unvalidated length parameters. Consequently, if an attacker or a maliciously crafted input provides oversized per-sample lengths, the native implementation will read past the allocated heap space. This behavior can lead to several severe operational impacts depending on the surrounding memory layout. In many cases, it results in immediate JVM termination due to segmentation faults or access violations triggered by the operating system's memory protection mechanisms. However, if the out-of-bounds data falls within a mapped but unmapped region that does not trigger an immediate fault, it may lead information disclosure by leaking sensitive data stored adjacent to the buffer in heap memory.
The operational impact of this vulnerability extends beyond simple application crashes. For services relying on zstd-jni for high-throughput compression tasks such as log aggregation, database backup systems, or real-time analytics pipelines, a denial-of-service condition can disrupt critical business operations. Furthermore, if the environment allows for controlled exploitation scenarios where memory layout is predictable, an attacker could potentially extract cryptographic keys, session tokens, or other sensitive information residing in nearby heap allocations. This aligns with ATT&CK technique T1005, which describes Data from Local System Retrieval via Memory Scraping. The vulnerability effectively turns a standard compression utility into a potential vector for both availability attacks and confidentiality breaches, particularly when processing untrusted input data streams that are not strictly validated by the calling application logic before being passed to the native library.
Mitigation strategies must focus on immediate version updates and defensive coding practices. The primary remediation is to upgrade zstd-jni to version 1.5.7-14 or later, where developers have implemented proper validation checks to ensure that the sum of per-sample lengths does not exceed the buffer's capacity before invoking native methods. For applications unable to update immediately due to dependency constraints, defensive programming measures should be adopted at the Java layer. Developers must manually verify that all sample length arrays are consistent with the actual size of the byte buffers being passed to trainFromBufferDirect and other similar JNI functions. Additionally, implementing strict input sanitization for any external data sources feeding into compression pipelines can reduce the attack surface. Regular security audits focusing on JNI interactions between Java code and native libraries are recommended to identify similar validation gaps in other components that bridge high-level application logic with low-level system operations.