Cargo yank hides a version from new dependency resolution but deletes nothing. Projects with an existing Cargo.lock keep building with the yanked version, and direct downloads still work. New projects or checkouts without a lockfile will not select it. So yank cannot recall a leaked secret or force anyone to upgrade.
How yank behaves
The Cargo book states that yank removes a published version from the server's index, does not delete any data, and leaves the crate available through the registry's download link. Cargo will not use a yanked version for any new project or checkout without a pre-existing lockfile, and it errors if no compatible versions remain for a dependent crate.
The docs give a worked table. If crate bar has versions 1.5.0, 1.5.1, 1.5.2, 2.0.0 and 3.0.0, and 1.5.0 is yanked, a requirement of 1.5.0 resolves to 1.5.1 or 1.5.2, an exact requirement of =1.5.0 returns an error, and a requirement of 2.0.0 uses 2.0.0.
Yank without breaking downstream
| Scenario | Effect |
|---|---|
| Yank a version nothing else can substitute | Dependents without a lockfile fail to resolve |
| Publish a compatible fix first, then yank | Dependents move to the fix, builds continue |
| Yank a version pinned exactly by others | They get an error until they change the requirement |
The Cargo docs recommend publishing a semver compatible version, such as 1.5.1, before yanking 1.5.0 so crates that depend on yours keep compiling.
When the docs say to yank
Crates should be yanked only in exceptional circumstances: an accidental publish, an unintentional semver break, or a significantly broken crate. For security vulnerabilities, the docs say the RustSec advisory database is typically a less disruptive way to inform users and encourage upgrades. For copyright, licensing or personal data problems, yanking may not be enough and you should contact the registry maintainers.
If credentials were published
Revoke them immediately. Cargo's docs point out that once a crate is published, you cannot tell whether leaked credentials were copied, and yanking cannot stop further spread because lock files and direct downloads are unaffected.
A response checklist
- Decide the problem type: bad code, vulnerability, secret, or legal.
- Publish the fix as a compatible version.
- Yank the bad version only if it is truly broken or dangerous to resolve.
- File an advisory for vulnerabilities so scanners can warn users with lockfiles.
- Rotate any leaked credential.
- Tell users which version to adopt.
For consumers
A lockfile protects you from surprise but also keeps you on a yanked or vulnerable version. Scan your lockfile, not only the manifest. See unpublish, yank and deprecate compared.
Safeguard's SBOM and dependency scanning reads lockfile versions and flags the ones with known advisories, so a vulnerable pinned crate does not hide behind a quiet yank.
Quick check
Does yanking stop existing builds?
No. Projects with a lockfile that already includes the version keep working, and direct downloads are unaffected.
Should I yank for a security vulnerability?
The Cargo docs say an advisory through RustSec is typically less disruptive. Publish a fixed version and file the advisory, then yank only if needed.
Sources
Last reviewed: 19 October 2026.
