Uninitialized memory exposed by `write::Decoder` on a corrupt legacy frame
Collected exploitation and prediction evidence
Risk source coverageCISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.
No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.
osv · RUSTSEC-2026-0392
PublishedFrom 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.
- Source published
- 16 Oct 2026 12:00:00 UTC
- Source modified
- 26 Oct 2026 14:00:05 UTC
- Observed here
- 26 Oct 2026 14:35:44 UTC
- Source terms
- OSV · upstream source license applies
Original source record · Cite this exact observation · Complete original publisher JSON
This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.