Unpublish, yank or deprecate: how registries pull a bad release

Registries use three different tools to retire a release. Unpublish removes it, tightly restricted. Yank hides it from new resolution without deleting it. Deprecate leaves it installable and adds a warning. None of them cleans up your own lockfiles, caches or builds, so you still have to act.

Side by side

• Unpublish (npm). New installs: the version is gone, subject to strict eligibility rules. Existing lockfiles: an install of that version fails once removed.
• Yank (Cargo, PyPI). New installs: hidden from normal selection. Existing lockfiles: keep working for exact pins or lock entries.
• Deprecate (npm). New installs: still work. Existing lockfiles: still install, with a warning.

Unpublish

The npm policy allows unpublishing only under conditions. Within 72 hours of publishing, it works if no other public package depends on yours. Later, all of these must hold: nothing depends on it, it had fewer than 300 downloads in the last week, and it has a single owner. A version number can never be reused, and an unpublish cannot be undone.

Because the rules are tight, a popular malicious package usually cannot simply be unpublished by its maintainer. Removal in those cases depends on the registry operators.

Yank

The Cargo documentation says yank removes a version from the index so new projects without a lockfile will not use it. The data is not deleted, and existing lock files and direct downloads are unaffected.

PyPI follows PEP 592. Installers must ignore yanked files when other versions satisfy the request, but may use one that is the sole match for an exact pin or a lock file entry. They should warn when they do.

Deprecate

The npm docs describe deprecation as keeping the package downloadable with a warning message. Deprecating a whole package also removes it from search results. It is a notice, not a block.

What each means when you are the consumer

1. After an unpublish, your build may fail on a missing version. Do not treat that as the end of the problem. Check whether you installed the version before it vanished, and whether copies survive in caches and images.
2. After a yank, nothing breaks for you if you have a lockfile, which is exactly why you could stay on a bad version unnoticed. Look for the yank warning in your logs.
3. After a deprecation, you get a warning only. Read the message, because it is the maintainer's explanation.

A response routine that works for all three

1. Search lockfiles and SBOMs for the package and version.
2. Read the maintainer's reason and any advisory.
3. Move to a fixed version, or remove the dependency, in a reviewed change.
4. Purge copies from internal caches and mirrors.
5. Rebuild and redeploy artifacts that contained it.
6. Rotate credentials that code in the package could have read at install, build or run time.
7. Write down the timeline.

What registries do not do for you

None of these actions tells you whether you were exposed. Only your own records do, so keep lockfile history, build logs and SBOMs for each release. Safeguard produces SBOMs and scans dependencies, and policies can block builds that include a flagged version, which closes the gap between a registry notice and a decision.

Quick check

Sources

• npm unpublish policy
• cargo yank documentation
• PEP 592, Adding yank support to the Simple API

Last reviewed: 19 October 2026.