How to find and replace a vulnerable transitive Rust crate with cargo tree -i

Step 01: Confirm the crate is in your lockfile

cargo audit                     # lists RUSTSEC IDs and the crate + version
grep -n 'name = "tokio-tar"' Cargo.lock

If the name is not in Cargo.lock, it is not in your build. Stop here.

Step 02: Invert the tree

cargo tree -i tokio-tar

cargo tree -i tokio-tar --workspace
cargo tree -i tokio-tar -p my-service
# several versions in the lockfile? name one:
cargo tree -i tokio-tar@0.3.1

The output reads bottom up. The first line is the bad crate; each indented line under it is something that depends on it; the last lines are your own packages.

How to read cargo tree -i: start at the bad crate, walk up to the first crate you control. Example names. Diagram by Tensorust.

Step 03: Find the feature that pulls it in

cargo tree -i tokio-tar -e features

This adds feature edges, so you see lines like opa-wasm feature "loader". If the bad crate sits behind an optional feature you do not use, set default-features = false on the parent in your Cargo.toml and enable only what you need. That is often a one-line fix with no fork.

Step 04: Pick the fix

Work down this list and stop at the first that works:

1. Upgrade the parent. cargo update -p <parent> takes the newest compatible release. Check its changelog; maybe it already moved off the bad crate. If it needs a new major version, bump it in Cargo.toml.
2. Turn off the feature you found in Step 3.
3. Swap your direct dependency. If you depend on the bad crate yourself, replace it. For tokio-tar: astral-tokio-tar = "0.7", the maintained fork from Astral, fixed since 0.5.6 (RUSTSEC-2025-0110). Rename it in code with use astral_tokio_tar as tokio_tar;.
4. Redirect it with a patch when a fixed fork keeps the same crate name:

[patch.crates-io]
some-crate = { git = "https://github.com/someone/some-crate", rev = "abc1234" }

[patch] only replaces a crate with one of the same name and a semver-compatible version, so it does not work for tokio-tar to astral-tokio-tar (different name). In that case, fork the middle crate, switch its dependency, patch the middle crate instead, and open a pull request upstream so everyone gets it.

5. Ask upstream. Open an issue on the parent crate with the RUSTSEC ID and the one-line change. As of Oct 28 2026, 28 crates on crates.io still need that issue for tokio-tar.

New releases are still choosing the crate with no fix. crates.io reverse dependencies, Oct 28 2026.

Step 05: Verify it is gone

cargo tree -i tokio-tar
# error: package ID specification `tokio-tar` did not match any packages
cargo audit
cargo test

That error is the success message.

Step 06: Stop it coming back

Add a gate to CI so the next abandoned crate fails the build instead of shipping. cargo deny check advisories or cargo audit both work; which one fits is in cargo audit vs cargo deny. For builds that must not touch the network at all, pair it with cargo vendor.