Vulnerability MediumRUSTSEC-2026-0384 · tokio
RUSTSEC-2026-0384: Race condition in `tokio::time::Interval` on Tokio v1.54.0
Short answerA security vulnerability in the tokio crate: Race condition in `tokio::time::Interval` on Tokio v1.54.0. GitHub rates it Medium. Fixed in 1.54.1: update to a fixed version.
| Crate | tokio |
|---|---|
| Type | Vulnerability (memory-corruption, thread-safety) |
| Affected versions | From 1.54.0 before 1.54.1. |
| Fixed in | 1.54.1 |
| Severity | Medium (GitHub rating) |
| Published | 2026-10-21 |
| Last changed | 2026-10-23 |
| Also known as | CVE-2026-115567, GHSA-5wjr-9356-4wc8 |
What to do
- See which version you have:
cargo tree -i tokio(it also shows which of your dependencies pulls it in). - Update within your version requirement:
cargo update -p tokio. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for exampletokio = "1.54.1") or update the dependency that pulls it in. - Check again with
cargo audit, or paste your Cargo.lock into our Cargo.toml checker.
Details from the advisory
Summary
On the multi-threaded runtime, there is a race condition between Interval::poll_tick and the runtime's time driver.
This affects Interval only. Sleep and Timeout are **not** affected.
Details
In Tokio v1.54.0, a race condition between tokio::time::Interval::poll_tick (including .tick().await) and the runtime time driver can drop an internal timer entry without synchronizing with the driver thread that is firing it. This causes a data race and use-after-free on the timer's waker and task state in safe Rust, leading to assertion panics, task reference-count corruption, or heap memory corruption.
This bug was introduced by https://github.com/tokio-rs/tokio/pull/8458, and it was fixed by https://github.com/tokio-rs/tokio/pull/8692.
Impact
This may lead to crashes and use-after-frees in applications using Interval on a multi-threaded runtime.
Since this issue is known to lead to crashes in production systems, the v1.54.0 release of Tokio has been yanked.
Credits
Thank you to creepycode and carabistouille for reporting this privately using the procedure outlined in our security policy. They both reported the issue independently of each other.
References
- Package: crates.io/crates/tokio
- Advisory: rustsec.org/advisories/RUSTSEC-2026-0384.html
- Web: github.com/tokio-rs/tokio/pull/8692
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 tokio
- VulnerabilityRUSTSEC-2021-0072 · 2021-07-07Task dropped in wrong thread when aborting `LocalSet` task
- VulnerabilityRUSTSEC-2021-0124 · 2021-11-16Data race when sending and receiving after closing a `oneshot` channel
- VulnerabilityRUSTSEC-2023-0001 · 2023-01-04reject_remote_clients Configuration corruption
- UnsoundRUSTSEC-2023-0005 · 2023-01-11`tokio::io::ReadHalf<T>::unsplit` is Unsound
- UnsoundRUSTSEC-2025-0023 · 2025-04-07Broadcast channel calls clone in parallel, but does not require `Sync`
- UnsoundRUSTSEC-2026-0386 · 2026-10-13`AsyncFd::new` and related constructors violate I/O safety
Up next
Same cratetokio: security historyEvery advisory for this crate, and whether it is safe to use today.Read it next →Did this answer your question?