cargo package report

Is stack_collections safe?

1 known vulnerability.

// reach

0 direct dependencies

none carry a known advisory

    0 packages depend on it

    an advisory here reaches each of them

      Create a free accountfor every dependency path, dependent and what to upgrade
      // ai model usage

      Tracked for PyPI packages. HuggingFace models declare Python dependencies, so cargo packages are not covered.

      cvss
      not scored

      severity out of 10

      epss
      not scored

      chance of exploitation in 30 days

      xyz score
      not scored

      CyberXYZ composite out of 10

      fig. 01 — RUSTSEC-2026-0301, the advisory selected below

      // 1 advisories

      RUSTSEC-2026-0301

      UNKNOWN
      // summary

      StackVec::retain committed its new length to self.len only after its internal loop completed. If the retain predicate or a removed element's Drop implementation panicked before the loop finished, unwinding proceeded with self.len still equal to the original, pre-retain length, leaving either a duplicated or already-destroyed element inside 0..len. StackVec's own Drop then revisited that slot, causing a double-drop (and for heap-owning types, a double-free).

      // impact

      Affects StackVec::retain for T: Drop types where the predicate or the removed element's destructor can panic, on builds with unwinding enabled (panic = "unwind"). nostd/panic = "abort" builds cannot trigger this, since unwinding never occurs.

      // patch

      Fixed in 0.3.3 using an unwind-safe backshift guard, matching the approach alloc::vec::Vec::retain uses.

      Checked 2026-09-24 at 08:33 UTC. The most recent advisory here was published 2026-09-22. Updated continuously from NVD, GHSA, OSV and CNA feeds.

      Think a verdict here is wrong? Tell us — we respond within 2 business days.
      Is stack_collections safe? cargo package security report | CyberXYZ