CVE-2026-90560

zstd-jni, the Java/JNI binding for Zstandard compression, does not validate the offset and length arguments passed to the ZstdDictDecompress constructor against the bounds of the dictionary byte array in all versions from 1.2.0 through 1.5.7-13 (CWE-125). An attacker who can influence the dictionary data or the offset/length values used to build a decompression dictionary — for example, through an application that accepts user-supplied dictionaries — can cause a read past the end of the array in native code. The realistic impact is denial of service via JVM termination, with at most limited information exposure, consistent with the CVSS 4.0 base score of 8.8 (network vector, no privileges or user interaction required, high availability impact). Any Java application that embeds an affected zstd-jni release and constructs ZstdDictDecompress from externally influenced parameters is affected; note that zstd-jni is commonly pulled in as a transitive dependency by data-infrastructure components such as kafka-clients. No public proof of concept is known, the issue is not in CISA's KEV catalog, and no exploitation in the wild has been reported.

What to do: Upgrade zstd-jni to a release newer than 1.5.7-13 (the latest available) everywhere it appears, including transitive dependencies that may pin an older version. If upgrading immediately is not feasible, add application-side validation that offset is non-negative, length is non-negative, and offset + length does not exceed the dictionary array length before constructing ZstdDictDecompress. Audit any decompression entry point that accepts externally supplied dictionaries (e.g., dictionary bytes from an API request or message payload), since those are the realistic attack surface for this flaw.