CVE-2026-87825

zstd-jni 1.3.8-4 through 1.5.7-13 Use-After-Free of Compression and Decompression Dictionaries

No known exploitation. EPSS puts it in the 9th percentile. Fixed in 1.5.7-14.

CVSS 3.17.7High EPSS percentile9th0.2% chance in 30 days CISA KEVNot listedNo confirmed exploitation
No public exploit known Fix1.5.7-14Upgrade to this build

Published 2026-09-09Updated 2026-09-14Sources: CVE.org, NVD

NVD CVE.org

What to do

Find your product and version, then upgrade to the build on the right.

Luben Zstd-jniAffected: ≥ 1.3.8-4, < 1.5.7-14Upgrade to: 1.5.7-14Stated by: CVE record

Versions as the sources state them. Full version matrix after sign-in

Steps

Written by AI from the record

Check your Java application's dependency list, build files, and deployed libraries for zstd-jni versions 1.3.8-4 through 1.5.7-13.
Upgrade zstd-jni to version 1.5.7-14.
Test compression and decompression jobs after upgrading, especially any that reuse dictionaries.
If you cannot upgrade promptly, ensure dictionaries are not closed until every stream and context using them has finished.

Usually a quick update

Check it yourselfA free OpenVAS check exists for this CVE. Run it against your hosts.Is your organisation exposed?Request an assessment to establish which checks fit your systems.

What it is

From the CVE record

zstd-jni before 1.5.7-14 contains a use-after-free vulnerability where streams and contexts hold a dictionary's shared lock only during the load call, allowing the dictionary to be closed while still referenced. Attackers can close a dictionary after associating it with a stream or context, causing subsequent read or write operations to access freed native memory, resulting in silent data corruption or JVM crashes.

In plain language

Written by AI from the record

zstd-jni 1.3.8-4 through 1.5.7-13 can corrupt data or crash Java applications, so small businesses using it should upgrade to 1.5.7-14.

A local, unauthenticated use-after-free in zstd-jni allows a compression or decompression dictionary to be closed while a stream or context still references its native memory, enabling integrity and availability impact.

If you're affected

Application crashes
Silent data corruption
Interrupted file processing
Service disruption

What is it

This is a flaw in a Java compression library that can leave a program holding a reference to memory that has already been released. It is like throwing away a paper file while someone is still using its contents: later work may use the wrong information or stop altogether.

Who is affected

This matters to you if you run Java software that includes zstd-jni for compression or decompression. It is primarily a risk where someone or some local process can trigger the affected dictionary-handling sequence.

How urgent is it

Attackers are not known to be exploiting this flaw, and no public exploit code is on record. Treat it as an amber-priority maintenance issue: upgrade in your normal near-term release window, with faster attention for systems where untrusted local activity can influence compression work.

What to do — in detail

Confirm exposure by inspecting Maven, Gradle, or other dependency manifests, packaged JARs, and dependency-lock files for zstd-jni versions before 1.5.7-14. The published fixed target is 1.5.7-14; no separate fixed-version branches are listed in the findings.

Upgrade the dependency to 1.5.7-14, rebuild the application, and test all compression and decompression paths that create, share, or reuse dictionaries. The findings do not identify a breaking-change requirement, but regression-test native-library loading and dictionary lifecycle behavior in your deployment environment.

If patching is delayed, do not close a dictionary until all streams and contexts associated with it have completed and been released; restrict untrusted local code or workflows from controlling this sequence. There is no CISA KEV due date because this CVE is not listed in KEV. Monitor application logs and process health for JVM crashes, native-memory faults, and unexpected compression or decompression output until the upgrade is deployed.

Technical context

CVE-2026-87825 is CWE-416, a use-after-free vulnerability rated CVSS 7.7 (High): CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H. A dictionary shared lock is held only during load, permitting the dictionary to be closed while an associated stream or context retains a native-memory reference; subsequent reads or writes can cause silent corruption or JVM crashes. CISA KEV does not list the CVE, and no public exploit code is on record. EPSS predicts 0.1% likelihood (3rd percentile) with a flat trend; exploit maturity is therefore unproven.

This is a general assessment based on public vulnerability data. It does not account for your specific infrastructure — when in doubt, consult a security specialist.

Exploitation

Where each signal puts this CVE on the scale from published to confirmed exploited.

EPSS9th

CISA KEV

Not in the catalog. CISA has not confirmed exploitation.

Public exploits

No public exploit or proof of concept found in the sources we track.

EPSS

0.2% chance of exploitation activity in the next 30 days, which ranks it in the 9th percentile of scored CVEs.

Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.

Lifecycle

7 events over 6 days, from the signal feeds we watch.

2026-09-15OpenVAS check added
2026-09-14Record updated
2026-09-09Publishedweakness classified, att&ck mapped, record updated, record updated

Affected products

luben
- zstd-jni

Technical detail

CVSS 3.1 vector

Open in the CVSS calculator

CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H

Scored 7.7 by NVD.

How it is reached

Attack Vector LocalRequires local access to the vulnerable system (e.g. local login, malicious file)
Attack Complexity LowNo special conditions — the attack can be reliably reproduced
Privileges Required NoneNo authentication required — anyone can exploit this
User Interaction NoneNo user interaction needed — fully automated exploitation

Scope

Scope UnchangedImpact is limited to the vulnerable component itself

Impact if exploited

Confidentiality NoneNo confidentiality impact
Integrity HighTotal loss of integrity — attacker can modify any data in the component
Availability HighTotal denial of service — the component is completely unavailable