tokio

Activity

Latest release: 1mo ago
Total releases: 195
Cadence: ~5 days
Last 12 months: 21

Details

License: MIT
First release: Jul 01, 2016

Releases

Version	Released
`1.53.1` unknown	Jul 20, 2026
`1.53.0` unknown	Jul 17, 2026
`1.52.4` unknown	Jul 16, 2026
`1.51.4` unknown	Jul 16, 2026
`1.52.3` unknown	May 08, 2026
`1.51.3` unknown	May 08, 2026
`1.47.5` unknown	May 07, 2026
`1.52.2` unknown	May 04, 2026
`1.51.2` unknown	May 04, 2026
`1.52.1` unknown	Apr 16, 2026
`1.52.0` unknown	Apr 14, 2026
`1.51.1` unknown	Apr 08, 2026
`1.51.0` unknown	Apr 03, 2026
`1.47.4` unknown	Apr 02, 2026
`1.50.0` unknown	Mar 03, 2026
`1.49.0` unknown	Jan 03, 2026
`1.47.3` unknown	Jan 02, 2026
`1.43.4` unknown	Jan 02, 2026
`1.47.2` unknown	Oct 14, 2025
`1.43.3` unknown	Oct 14, 2025
`1.48.0` unknown	Oct 14, 2025
`1.47.1` unknown	Aug 01, 2025
`1.43.2` unknown	Aug 01, 2025
`1.47.0` unknown	Jul 26, 2025
`1.46.1` unknown	Jul 04, 2025
`1.46.0` unknown	Jul 02, 2025
`1.45.1` unknown	May 24, 2025
`1.45.0` unknown	May 06, 2025
`1.42.1` unknown 1 CVE	Apr 08, 2025
`1.44.2` unknown	Apr 05, 2025
`1.43.1` unknown	Apr 04, 2025
`1.38.2` unknown	Apr 03, 2025
`1.44.1` unknown 1 CVE	Mar 13, 2025
`1.44.0` unknown 1 CVE	Mar 07, 2025
`1.43.0` unknown 1 CVE	Jan 08, 2025
`1.42.0` unknown 1 CVE	Dec 03, 2024
`1.41.1` unknown 1 CVE	Nov 07, 2024
`1.41.0` unknown 1 CVE	Oct 22, 2024
`1.40.0` unknown 1 CVE	Aug 30, 2024
`1.39.3` unknown 1 CVE	Aug 17, 2024
`1.39.2` unknown 1 CVE	Jul 27, 2024
`1.39.1` unknown 1 CVE	Jul 23, 2024
`1.39.0` unknown yanked 1 CVE	Jul 23, 2024
`1.38.1` unknown 1 CVE	Jul 16, 2024
`1.38.0` unknown 1 CVE	May 30, 2024
`1.37.0` unknown 1 CVE	Mar 28, 2024
`1.36.0` unknown 1 CVE	Feb 02, 2024
`1.35.1` unknown 1 CVE	Dec 19, 2023
`1.32.1` unknown 1 CVE	Dec 19, 2023
`1.25.3` unknown 1 CVE	Dec 19, 2023

1–50 of 195

Dependencies (33)

Depends on

1.53.1

Used by

76311

Supply-chain exposure

76,311 tracked projects depend on this, <1% of every package we track.

A known CVE here directly exposes every one of them.

Known CVEs (5)

GHSA-rr8g-9fpq-6wmg RUSTSEC-2025-0023 Apr 07, 2025

Tokio broadcast channel calls clone in parallel, but does not require `Sync`

Low
Network Low None None

The broadcast channel internally calls clone on the stored value when receiving it, and only requires T:Send. This means that using the broadcast channel with values that are Send but not Sync can trigger unsoundness if the clone implementation makes use of the value being !Sync.

Thank you to Austin Bonander for finding and reporting this issue.

Fixed in

1.38.21.43.11.44.2

References

https://github.com/tokio-rs/tokio/pull/7232
https://github.com/tokio-rs/tokio
https://rustsec.org/advisories/RUSTSEC-2025-0023.html

Updated Sep 10, 2026 · Source: OSV.dev
GHSA-4q83-7cq4-p6wg RUSTSEC-2023-0005 Feb 04, 2023

`tokio::io::ReadHalf<T>::unsplit` is Unsound

Low

tokio::io::ReadHalf<T>::unsplit can violate the Pin contract

The soundness issue is described in the tokio/issues#5372

Specific set of conditions needed to trigger an issue (a !Unpin type in ReadHalf) is unusual, combined with the difficulty of making any arbitrary use-after-free exploitable in Rust without doing a lot of careful alignment of data types in the surrounding code.

The tokio feature io-util is also required to be enabled to trigger this soundness issue.

Thanks to zachs18 reporting the issue to Tokio team responsibly and taiki-e and carllerche appropriately responding and fixing the soundness bug.

Tokio before 0.2.0 used futures 0.1 that did not have Pin, so it is not affected by this issue.

Fixed in

1.18.51.20.41.24.2

References

https://github.com/tokio-rs/tokio/issues/5372
https://github.com/tokio-rs/tokio
https://rustsec.org/advisories/RUSTSEC-2023-0005.html

Updated Sep 10, 2026 · Source: OSV.dev
CVE-2023-22466 GHSA-7rrj-xr53-82p7 RUSTSEC-2023-0001 Jan 06, 2023

Tokio reject_remote_clients configuration may get dropped when creating a Windows named pipe

5.4 / 10
Medium
Network Low Low None Unchanged Low None Low

Impact

When configuring a Windows named pipe server, setting pipe_mode will reset reject_remote_clients to false. If the application has previously configured reject_remote_clients to true, this effectively undoes the configuration. This also applies if reject_remote_clients is not explicitly set as this is the default configuration and is cleared by calling pipe_mode.

Remote clients may only access the named pipe if the named pipe's associated path is accessible via a publically shared folder (SMB).

Patches

The following versions have been patched:

1.23.1

1.20.3

1.18.4

The fix will also be present in all releases starting from version 1.24.0.

Named pipes were introduced to Tokio in version 1.7.0, so releases older than 1.7.0 are not affected.

Workarounds

Ensure that pipe_mode is set first after initializing a ServerOptions. For example:

let mut opts = ServerOptions::new(); opts.pipe_mode(PipeMode::Message); opts.reject_remote_clients(true);

References

https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createnamedpipea#pipe_reject_remote_clients

Fixed in

1.18.41.20.31.23.1

References

https://github.com/tokio-rs/tokio/security/advisories/GHSA-7rrj-xr53-82p7
https://nvd.nist.gov/vuln/detail/CVE-2023-22466
https://github.com/tokio-rs/tokio/pull/5336
https://github.com/tokio-rs/tokio
https://github.com/tokio-rs/tokio/releases/tag/tokio-1.23.1
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createnamedpipea#pipe_reject_remote_clients

Updated Sep 10, 2026 · Source: OSV.dev
CVE-2021-45710 GHSA-fg7r-2g4j-5cgr RUSTSEC-2021-0124 Jan 06, 2022

Race Condition in tokio

8.1 / 10
High
Network High None None Unchanged High High High

If a tokio::sync::oneshot channel is closed (via the oneshot::Receiver::close method), a data race may occur if the oneshot::Sender::send method is called while the corresponding oneshot::Receiver is awaited or calling try_recv.

When these methods are called concurrently on a closed channel, the two halves of the channel can concurrently access a shared memory location, resulting in a data race. This has been observed to cause memory corruption.

Note that the race only occurs when both halves of the channel are used after the Receiver half has called close. Code where close is not used, or where the Receiver is not awaited and try_recv is not called after calling close, is not affected.

Fixed in

1.8.41.13.1

References

https://nvd.nist.gov/vuln/detail/CVE-2021-45710
https://github.com/tokio-rs/tokio/issues/4225
https://github.com/tokio-rs/tokio
https://raw.githubusercontent.com/rustsec/advisory-db/main/crates/tokio/RUSTSEC-2021-0124.md
https://rustsec.org/advisories/RUSTSEC-2021-0124.html

Updated Nov 08, 2023 · Source: OSV.dev
CVE-2021-38191 GHSA-2grh-hm3w-w7hv RUSTSEC-2021-0072 Aug 25, 2021

Race condition in tokio

5.9 / 10
Medium
Network High None None Unchanged None None High

When aborting a task with JoinHandle::abort, the future is dropped in the thread calling abort if the task is not currently being executed. This is incorrect for tasks spawned on a LocalSet. This can easily result in race conditions as many projects use Rc or RefCell in their Tokio tasks for better performance.

Fixed in

1.5.11.6.31.7.21.8.1

References

https://nvd.nist.gov/vuln/detail/CVE-2021-38191
https://github.com/tokio-rs/tokio/issues/3929
https://github.com/tokio-rs/tokio
https://raw.githubusercontent.com/rustsec/advisory-db/main/crates/tokio/RUSTSEC-2021-0072.md
https://rustsec.org/advisories/RUSTSEC-2021-0072.html

Updated Nov 08, 2023 · Source: OSV.dev

Insights

Releases per month

last 12 months

Release mix

unknown 195

195 releases

Dependencies over time

per release

Release calendar

2026

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Less More