RUSTSEC-2026-0005: Potential use-after-free in `oneshot` when used asynchronously

What to do

1. See which version you have: cargo tree -i oneshot (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p oneshot. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example oneshot = "0.1.12") 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

There is a race condition that can lead to a use-after-free if a oneshot::Receiver is polled but then dropped instead of polled to completion. This could happen if the receiver future was cancelled while receiving, for example by being wrapped in a timeout future or similar.

When the Receiver is polled (Future::poll) it writes a waker to the channel and sets it to the RECEIVING state. If the Receiver was then dropped (instead of polled to completion), the Drop implementation on Receiver unconditionally swapped the channel state to DISCONNECTED and only after doing so it read back its waker from the heap allocation and dropped it. The problem is that the DISCONNECTED state could be observed by the Sender, which would lead to it deallocating the channel heap memory. If the Sender manage to free the channel before the Receiver managed to proceed to dropping the waker, then the Receiver would read from the freed channel memory (use-after-free).

The fix was submitted in https://github.com/faern/oneshot/pull/74 and published as part of oneshot version 0.1.12.

References

• Package: crates.io/crates/oneshot
• Advisory: rustsec.org/advisories/RUSTSEC-2026-0005.html
• Report: github.com/faern/oneshot/issues/73

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