npm allows unpublishing only under tight conditions, mainly within 72 hours of publishing or when almost nobody uses the package. A removed version number can never be reused. For your team, that means a bad release can linger in lockfiles and caches long after the registry page changes.
The rules in plain terms
According to the npm policy page, you can unpublish a package if no other public package depends on it and it was published in the last 72 hours.
After 72 hours, three conditions must all hold:
- No other package in the public registry depends on it.
- It had fewer than 300 downloads over the last week.
- It has a single owner or maintainer.
There are two more limits worth knowing. A package at a given version can never be reused, even after unpublishing, so a fix must ship under a new version number. And after unpublishing every version, nobody can publish new versions of that package name until 24 hours have passed. An unpublish cannot be undone.
Deprecation is the usual alternative
If a package does not meet the criteria, npm points maintainers to deprecation. A deprecated package stays downloadable but shows a warning message when installed. Deprecating a whole package also drops it from search results.
Deprecation is a notice, not a block. Installs still work, and automation that ignores warnings keeps pulling the version.
What this means for you
Think about the three places a bad version can survive.
- Your lockfile. It records the exact version and an integrity hash. A lockfile install keeps asking for that version whether or not the registry still lists it.
- Caches and mirrors. An internal proxy or a CI cache may hold the tarball. Removal upstream does not clear your copy.
- Built artifacts. Images and bundles produced while the bad version was live still contain it.
So when a package you use is reported malicious, do not wait for the registry to remove it. Act in your own systems:
- Search every lockfile and SBOM for the package and version.
- Pin to a known good version or remove the dependency, and regenerate the lockfile.
- Purge the version from internal caches and mirrors.
- Rebuild and redeploy artifacts that included it.
- Rotate any secrets that the build or runtime could have read. Install scripts run with the access of the installing user.
- Record the timeline, including when you installed it and when you removed it.
A note on reading the registry
A package page that returns not found after an incident does not tell you whether you were exposed. Your own build logs and lockfile history do. Keep them long enough to answer that question later.
If you want an inventory to search quickly, Safeguard produces SBOMs and scans dependencies, so a question like "where did we use this version" becomes a lookup instead of a hunt.
Quick check
Can a maintainer republish the same version after unpublishing it?
No. A package at a given version can never be reused, even after it is unpublished, so a corrected release needs a new version number.
Does deprecating a package stop people installing it?
No. It keeps the package downloadable and shows a warning. It is a notice and does not block installs.
Sources
Last reviewed: 19 October 2026.
