Yanking a crate version removes it from the registry index so new projects will not pick it, but it does not delete the data, and existing lockfiles keep working. If a crate you use is found to be bad, a yank upstream is not enough. You must remove or replace it yourself.
What yank does
The Cargo documentation says the yank command removes a previously published crate version from the server's index. Cargo will not use a yanked version for any new project or checkout without a pre-existing lockfile. It will produce an error if no compatible versions remain.
What yank does not do
Two statements in the docs matter most for security.
- The command does not delete any data. The crate remains available for download through the registry's download link.
- Existing lock files and direct downloads are not affected. The docs say this means yanking cannot stop further spreading of leaked credentials.
So a project with a lockfile that already names the yanked version keeps building against it. Anyone who fetches the download link directly can still get the files.
When maintainers should yank
The documentation frames yanking as meant for exceptional cases, such as an accidental publish, unintentional breakage of semantic versioning, or a seriously broken crate. For security vulnerabilities, it recommends RustSec as the less disruptive option. It also advises publishing a semver compatible fix first, for example a patch release, before yanking a breaking one so dependents keep working. Yanks can be undone.
What consumers should do
Treat a yank as a hint, not a resolution.
- Find your exposure. Search lockfiles and SBOMs for the crate and version. A yank notice may be the only public signal you get.
- Update the lock. Move to a fixed or earlier clean version and regenerate the lockfile in a reviewed pull request.
- Check the advisory database. If the issue is a vulnerability, look for a RustSec entry and run an audit tool in CI.
- Rotate secrets if the crate could have run code at build or runtime with access to credentials. Build scripts and procedural macros execute during compilation.
- Rebuild and redeploy anything produced with the bad version.
What to watch for in CI
A build that fails to resolve after a yank means you lack a lockfile or are asking for a version that no longer qualifies. Do not respond by pinning the yanked version through some other route. Find out why it was yanked first.
Also watch the reverse case: a clean looking build that still uses a yanked version because the lockfile has it. Add a check that lists lockfile entries and compares them with advisory data, and treat yanked status as a reason to look, not as a pass or fail on its own.
Reporting a malicious crate
If you believe a crate is malicious, report it to the registry operators through their stated channels, because only they can remove content. Do not assume a maintainer's yank will do it. Note that copyright, licensing or personal data matters may also need the registry team.
Safeguard scans Rust dependencies and generates SBOMs, which gives you the quick lookup in step one, and policies can gate a release when a flagged component is present.
Quick check
Will my existing build break when a crate version is yanked?
Not if you have a lockfile that already names it. The docs say existing lock files are not affected.
Is yanking the right way to handle a vulnerability?
The Cargo docs recommend RustSec as the less disruptive option for security vulnerabilities and reserve yanking for exceptional cases.
Sources
Last reviewed: 19 October 2026.
