CVE-2026-87877 in zstd-jni
Summary
by MITRE • 09/09/2026
zstd-jni versions before 1.5.7-14 fail to validate closed state in setDict, setLongMax, setLevel and setRefMultipleDDicts methods of stream classes. Attackers can call these methods on closed streams to write through freed native pointers, corrupting unrelated objects or crashing the JVM.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in zstd-jni versions prior to 1.5.7-14 represents a critical failure in resource management and state validation within the Java Native Interface layer of the Zstandard compression library integration. This flaw specifically affects methods responsible for configuring stream parameters, including setDict, setLongMax, setLevel, and setRefMultipleDDicts. These functions are designed to modify operational settings on an active zstd stream instance, such as setting dictionary references, adjusting maximum sequence lengths, defining compression levels, or updating reference dictionaries. However, the underlying implementation fails to verify whether the native C++ object associated with the Java wrapper has already been closed or deallocated before proceeding with these configuration operations. This oversight creates a dangerous gap in the lifecycle management of the stream objects, allowing for improper state transitions that lead to severe memory safety violations.
From a technical perspective, this issue is classified as an out-of-bounds write resulting from use-after-free conditions. When a developer or automated process invokes any of the affected methods on a stream object that has previously been closed via its close method, the Java wrapper continues to pass references to native pointers that have already been freed by the garbage collector and subsequent C++ destructor calls. Consequently, the underlying zstd library attempts to write configuration data into memory locations associated with these invalid pointers. Since this memory may no longer be allocated for the stream object or may have been reallocated for other purposes, the writes corrupt unrelated objects in the heap space. This corruption can manifest as subtle data integrity issues, unpredictable application behavior, or immediate crashes of the Java Virtual Machine due to segmentation faults triggered by accessing freed memory regions.
The operational impact of this vulnerability is significant, particularly in environments where zstd-jni is used for high-throughput data processing services such as web servers, database proxies, or big data pipelines. An attacker who can influence the lifecycle management of these stream objects could exploit this flaw to cause a denial of service by crashing the JVM, thereby disrupting availability for all users connected to the affected system. Furthermore, if the application logic allows an attacker to control the input parameters passed to setDict or similar methods while simultaneously manipulating the timing of close calls through race conditions or crafted API usage patterns, the memory corruption could potentially be leveraged for arbitrary code execution. Although achieving reliable exploitation in a managed environment like Java is complex due to heap randomization and other mitigations, the potential severity remains high because it bypasses standard type safety checks inherent to the JVM by interacting directly with native memory through JNI calls.
This vulnerability aligns with CWE-416, Use After Free, as the core issue involves accessing memory after it has been released back to the system or garbage collector. It also relates to CWE-20, Improper Input Validation, specifically regarding the failure to validate the state of an object before performing operations that depend on its validity. In terms of attack vectors and techniques, this flaw can be mapped to MITRE ATT&CK technique T1499, Endpoint Denial of Service, if exploited for crashes, or potentially T1055, Process Injection, if the memory corruption is manipulated to alter control flow in native libraries loaded by the JVM. The lack of state validation makes it a prime candidate for exploitation through automated fuzzing tools that systematically test edge cases around object lifecycle boundaries.
Mitigation strategies must prioritize immediate version upgrades and robust defensive coding practices. The most effective remediation is to upgrade zstd-jni to version 1.5.7-14 or later, where the developers have implemented proper checks to ensure that stream objects are in an open state before allowing configuration methods to execute. For applications unable to update immediately due to dependency constraints, defensive programming patterns should be adopted within the Java codebase. Developers must explicitly track the lifecycle of zstd stream instances and prevent any method calls on streams marked as closed or disposed. Implementing wrapper classes that enforce a strict state machine for stream operations can help mitigate this risk by throwing exceptions when methods are called on invalid states rather than passing control to the vulnerable native layer. Additionally, enabling core dumps in production environments can aid in forensic analysis if crashes occur, helping to identify instances where these specific JNI calls were made against closed streams.