Quick answers
- Is This vulnerability exploited in the wild?
- No. Junglewise Threat Intelligence has no report of This vulnerability being exploited in the wild.
- How severe is This vulnerability?
- Informational severity, published 16 October 2026.
- Which products and versions are affected?
- zstd-safe (crates.io) SEMVER:introduced=4.1.4,fixed=8.2.0; Zstd-Safe 4.1.4 to before 8.2.0.
- Is there a fix for This vulnerability?
- Yes. zstd-safe (crates.io): upgrade to 8.2.0 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
- How is This vulnerability attacked?
- It is attacked with local access, in a software library.
- Am I affected?
- Check whether you run zstd-safe (crates.io) or Zstd-Safe at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.
How to fix
- zstd-safe (crates.io): upgrade to 8.2.0 or later
cargo update -p zstd-safe
Technical details
The DCtx::try_clone function performs an unsafe, shallow copy of a compression context structure without properly transferring ownership of resources. When a context owns a dictionary (via load_dictionary, ref_prefix, or init_using_dict) or a dictionary table (via ref_ddict with RefMultipleDDicts), both the original and cloned context attempt to free the same memory, causing a double-free. Additionally, cloning mid-frame leaves the cloned context with uninitialized stream state and loses the WindowLogMax limit parameter. The vulnerability is fixed by rejecting clones of such contexts and properly transferring parameters.
Affected products
- zstd-safe 4.1.4 to before 8.2.0
Timeline
- 2026-10-16: disclosed
- 2026-10-26: patched