RUSTSEC-2024-0005: Unsound sending of non-Send types across threads

What to do

1. See which version you have: cargo tree -i threadalone (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p threadalone. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example threadalone = "0.2.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 can run the Drop impl of a non-Send type on a different thread than it was created on.

The flaw occurs when a stderr write performed by the threadalone crate fails, for example because stderr is redirected to a location on a filesystem that is full, or because stderr is a pipe that has been closed by the reader.

Dropping a non-Send type on the wrong thread is unsound. If used with a type such as a pthread-based MutexGuard, the consequence is undefined behavior. If used with Rc, there would be a data race on the reference count, which is likewise undefined behavior.

References

• Package: crates.io/crates/threadalone
• Advisory: rustsec.org/advisories/RUSTSEC-2024-0005.html
• Report: github.com/cr0sh/threadalone/issues/1

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