RUSTSEC-2020-0116: PinSlab<T> and Unordered<T, S> need bounds on their Send/Sync traits

What to do

1. See which version you have: cargo tree -i unicycle (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p unicycle. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example unicycle = "0.7.1") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

Affected versions of this crate unconditionally implemented Send & Sync for types PinSlab<T> & Unordered<T, S>. This allows sending non-Send types to other threads and concurrently accessing non-Sync types from multiple threads.

This can result in a data race & memory corruption when types that provide internal mutability without synchronization are contained within PinSlab<T> or Unordered<T, S> and accessed concurrently from multiple threads.

The flaw was corrected in commits 92f40b4 & 6a6c367 by adding trait bound T: Send to Send impls for PinSlab<T> & Unordered<T, S> and adding T: Sync to Sync impls for PinSlab<T> & Unordered<T, S>.

References

• Package: crates.io/crates/unicycle
• Advisory: rustsec.org/advisories/RUSTSEC-2020-0116.html
• Report: github.com/udoprog/unicycle/issues/8

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.

Other advisories for unicycle

• VulnerabilityRUSTSEC-2026-0298 · 2026-09-12Use-after-free when a future's `Drop` panics while the container is dropped

Full security history of unicycle