RUSTSEC-2026-0392 json
Uninitialized memory exposed by `write::Decoder` on a corrupt legacy frame
published 26d ago modified 16d ago
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
From 0.4.22 to 0.7.x, the writer behind `zstd::stream::write::Decoder` set its output buffer's length to its full capacity before each decompression call, then to the position the call reported, and only checked for an error afterwards. When decompression fails inside a legacy (zstd v0.4 to v0.7) frame, the bundled zstd library reports the output as fully written although nothing was written, so stale heap memory, up to the buffer size (32 KiB by default), was passed to the wrapped writer.
Legacy support is enabled by default, and a few bytes of corrupt legacy frame are enough. Whether this reaches an attacker depends on where the application sends the decompressed output.
From 0.8.0, the writer uses zstd-safe's buffers, and the same flaw there is covered by the zstd-safe advisory for it, fixed in zstd-safe 8.2.0.
Patch / fix
- crates.io zstd 0.8.0
- github.com/gyscos/zstd-rs@006e1d1 commit
- github.com/gyscos/zstd-rs#384 pull request
Is RUSTSEC-2026-0392 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| crates.io | zstd | >=0.4.22, <0.8.0 |
0.8.0 |
References
Sources
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.