No. The large public registries treat a published version as fixed. npm, PyPI and Maven Central do not let you replace the contents of a version once it is out, and crates.io only lets you yank one, which hides it from new resolution without deleting data. The fix is always a new version.
What each registry says
| Registry | Can you replace the files? | What you can do instead |
|---|---|---|
| npm | No. A name and version can never be reused, even after unpublish | Deprecate, or publish a new version |
| PyPI | No. A filename cannot be reused, even after the project is deleted and recreated | Publish a new release |
| Maven Central | No. Components are not removed or modified once public | Publish a patch release |
| crates.io | Yank only. Data stays downloadable | Yank, then publish a fixed version |
The wording comes from each registry's own documentation. npm describes registry data as immutable and says a published name and version can never be used again. PyPI states that a distribution filename, made of project name, version and distribution type, always resolves to the same file. Maven Central says it does not remove or modify components once available, and ties that to the expectation that builds are repeatable. Cargo's yank command removes a version from the index but, in its own words, does not delete any data.
Why registries are built this way
Your lockfile records a version, and often a hash. If a maintainer could swap the files behind a version, the hash would stop matching or, worse, nobody would notice. Immutability is what makes "the same version" mean "the same bytes".
It also limits what an attacker can do after taking over a maintainer account. They cannot quietly rewrite 1.4.2 in place. They have to publish a new version, which shows up in release feeds, diffs and scanners. That is not full protection, since a new malicious version is still a problem, but it removes a stealthy class of attack.
What to do when you shipped a bad release
- Stop the bleeding. Deprecate or yank the bad version so new installs avoid it where the registry supports that.
- Publish a fixed version with a higher number. Patch increments signal compatibility if you follow semantic versioning.
- Tell users which version to move to, with the reason.
- If the release contained a secret, rotate the secret. Removal from the registry does not recall copies already downloaded or mirrored.
What this means for consumers
Pin versions in a lockfile, keep the hashes, and treat "same version, different content" as an alarm. Your private mirror or cache may hold the old bytes even after the registry changes, so know which source your builds really read. See what happens to your mirror when upstream removes a package and unpublish, yank and deprecate compared.
Safeguard's SBOM and dependency scanning records the exact versions in each build, so a yanked or replaced release can be found across your projects. You can try it with the free scan.
Quick check
Can I unpublish an npm version and reuse the number?
No. npm's policy says once a package at a given version has been used you can never use that name and version again, even if you unpublished it.
Does yanking a crate delete it?
No. Cargo documents that yank does not delete any data, and the crate stays downloadable through the registry link. Existing lockfiles can still resolve it.
Sources
- npm Unpublish Policy
- PyPI Help
- Immutability of Published Components, Maven Central
- cargo-yank, The Cargo Book
Last reviewed: 19 October 2026.
