No. Maven Central states that it does not remove or modify components once they are publicly available. If a release has a bug or a vulnerability, the maintainer publishes a new version, and you have to move to it yourself or exclude the bad one.
What the policy says
The Central documentation on immutability explains the reasoning. When a project depends on a specific version, users expect to build it repeatably. Central therefore provides every dependency exactly as originally published. Required checksums and GPG signatures let users prove that what they download today is the same as yesterday and came from a verifiable person or organisation.
For a faulty component, the documentation names the path: publish a new release with the fix. If the project uses Semantic Versioning, a patch release best signals that it is compatible with the previous version. Then the maintainer should broadcast the new release through their communication channels.
What that means for consumers
Registries differ. Some let maintainers yank or deprecate a version so tools stop selecting it by default. On Maven Central, the bad file stays. Your build will keep resolving it if you pinned that version, and nothing on the registry itself will warn you.
So your defence has to live in your build and your monitoring:
| Situation | Response |
|---|---|
| You pin the bad version | Update the pin to the fixed release |
| A transitive dependency brings it in | Override or constrain the version in your build tool |
| The maintainer has not fixed it yet | Exclude the artifact or replace it, and record why |
| You depend on a version range | Check what the range resolves to today |
Steps when you hear a release is bad
- Confirm the artifact and version from the maintainer's own announcement or advisory.
- Search your dependency tree, including transitive paths, for that exact version.
- Move to the fixed version, using the build tool's dependency management section so every module agrees.
- Rebuild and rerun tests. Container images and shaded jars need a rebuild too, because the old class files are baked in.
- Check any artifact stores or mirrors you operate. A mirror may still serve the bad version to other teams.
- Record the change.
Step four is easy to miss. A shaded or fat jar can carry a copy of the bad library inside, so a dependency tree alone will not show it.
Why immutability is still good
The same property that stops removal protects you from silent replacement. If a component could be swapped after publication, a compromised account could change what you build against. With checksums and signatures fixed at release, a changed file is detectable. The trade off is that cleanup is your job.
If you run an internal repository, consider adding a block rule for known bad coordinates so builds fail fast instead of relying on each developer to remember. See our write up on yank, delete or deprecate options across registries.
Where Safeguard fits
Safeguard's SBOM and dependency scanning identifies where a specific artifact version appears in your repositories, and policies and gates can stop a build that includes it. You can try a free scan at gold.safeguard.sh/scan.
Quick check
If Maven Central keeps the bad version, will my build use it?
It will if you pin it, or if a range or transitive path still resolves to it. Update the pin or constrain the version.
What should a maintainer do instead of removal?
Per the Central documentation, publish a new release with the fix, ideally a patch release under semantic versioning, and tell users.
Sources
Last reviewed: 19 October 2026.
