No. Maven Central's published policy is that it does not remove or modify components once they are publicly available. If a release has a bug or a vulnerability, the maintainer ships a newer version. Your build keeps resolving the old one until you change it.
What the policy says
Sonatype's documentation on immutability says that to provide reliable access to open source components, components are not removed or modified after publication. The reasoning given is repeatability: when a project depends on a specific version, users expect to build it the same way later, so Central must provide every dependency exactly as originally published.
The same page ties this to two requirements. Checksums and GPG signatures let users prove that the version downloaded today is the same as the one downloaded yesterday, and that it came from a verifiable person or organization.
For a component with a bug, the documented path is a new release with a fix, ideally a patch release under semantic versioning, then announcing it to users.
What that means for your risk
The upside is stability. A version you pinned will not vanish or change under you.
The downside is that a vulnerable version stays downloadable forever. Nothing on the registry side will warn your build or stop it from resolving. The vulnerable jar sits in your lock files, your caches and your internal repository mirror until you act.
So the work moves to you:
- Know what you resolve. Generate an SBOM for each release so you can search by component and version.
- Watch for advisories against those versions continuously, not only at build time.
- Upgrade to the fixed release and rebuild.
- Check the internal mirror and CI caches so old copies are not still served.
Where removal confusion comes from
Teams sometimes expect a registry takedown to act as a safety net. Central's model does not work that way, so build your process on the assumption that a flagged version will stay available. The Maven documentation on 3.8.1 makes a related point about immutability: uploaded POMs on Central are immutable, which is why Maven itself had to change behavior to block insecure HTTP repositories, rather than asking for old POMs to be fixed. See our post on why Maven blocks HTTP repositories.
A practical routine
| Event | Your action |
|---|---|
| Advisory names a version you use | Find every build that contains it, using SBOMs |
| Fixed release exists | Bump the version, rebuild, redeploy |
| No fix yet | Check reachability, apply a mitigation, track it |
| Old jar still in a cache | Purge it from the repository manager and CI caches |
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a finding links straight to the fixed version, which is the step the registry will never do for you.
Safeguard scans your Maven and Gradle dependencies, uses reachability analysis to show which findings affect code you actually call, and can open fix pull requests. That remediation is off by default and every category starts on Manual. Free scan: gold.safeguard.sh/scan.
Quick check
If a library is compromised, will Central pull it?
Central's documented policy is that it does not remove or modify components once published. Do not plan around a takedown. Plan around detecting and upgrading.
Why are signatures and checksums required then?
They let you prove a downloaded file is the same one that was published and that a verifiable party published it.
Sources
- Immutability of Published Components, Sonatype Central documentation
- Requirements, Sonatype Central documentation
- Maven 3.8.1 release notes
Last reviewed: 19 October 2026.
