Request for Comments: CARE and Maven Central

Site Search

Site Search

Login

Contact Us

Book a Demo

This is a search field with an auto-suggest feature attached.

There are no suggestions because the search field is empty.

Resources

Blog

Request for Comments: CARE, Emergency Remediation, and ...

Request for Comments: CARE, Emergency Remediation, and Maven Central

July 13, 2026

By Brian Fox

6 minute read time

Request for Comments: CARE and Maven Central

9:05

For most of Maven Central's history, publishing has followed a simple model: maintainers publish releases, users consume them, and when something goes wrong, the fix comes through the same channel.

That model still works most of the time. It is also the model we want to preserve.

But the world around it is changing.

A growing group of security researchers, maintainers, vendors, foundations, and infrastructure operators have been working through what AI-accelerated vulnerability discovery means for open source. The Akrites project is one part of that conversation. Its central observation is simple enough: when machines can find vulnerabilities faster than humans can coordinate fixes, the bottleneck moves. Discovery is no longer the hard part by itself. Validation, triage, disclosure, repair, and deployment become the scarce resources.

That matters for Maven Central because Central is not just a file server. It is part of the dependency graph's trust fabric. A single artifact may sit several layers deep in thousands or millions of applications. When one of those artifacts is vulnerable, the cleanest answer is always upstream repair: maintainers publish a fixed release, consumers upgrade, and the graph moves forward.

But not every project is active. Not every maintainer is reachable. Not every component still has an upstream capable of responding quickly. Some projects are end-of-life and still everywhere. Some fixes will be backports to old lines that no one expected to touch again. And in those moments, telling the world to move to a brand-new namespace is often technically correct in the way only technically correct answers can be: accurate, principled, and operationally miserable.

In Maven, coordinates are identity. Moving from one groupId:artifactId to another is not a rename. It can create duplicate classes, version collisions, broken dependency mediation, and a long tail of transitive dependency cleanup. That is not what you want during an emergency.

So we are proposing a draft policy for a narrow mechanism inside Maven Central: a way for Central, working with preapproved trusted remediation actors, to approve emergency remediation releases into existing coordinates when that is the safest path for the ecosystem.

This is intentionally a Maven Central publication policy. It defines when Central may authorize an emergency remediation release under an existing coordinate. It does not change how Maven, Gradle, repository managers, scanners, dependency bots, or other tools resolve or recommend versions.

Introducing the Maven Central CARE Program

We are calling this draft policy the Maven Central CARE Program : Central Approved Remediation for Emergencies .

CARE is intentionally narrow: ordinary maintainer publication remains the preferred path; original maintainers do not lose their rights; emergency releases must be reviewed and validated; trusted remediation actors must work in coordination with Central; and CARE releases are for security remediation, not features, modernization, rebranding, or project takeover.

Before getting into version numbers, it's worth being clear about the scope of the proposal. CARE isn't trying to decide when consumers should upgrade, how dependency bots should behave, or how scanners should prioritize findings. Those decisions remain with the broader ecosystem. The question here is much narrower: if a trusted remediation exists but the ordinary maintainer publication path isn't available, what should Maven Central publish?

The full draft has the details. This post is mostly about the shape of the idea and the part we most need the community to stress-test: versioning.

The Versioning Problem

If a vulnerable project is still maintained, the answer is easy:

But suppose 1.2.3 is vulnerable and the project is dormant. A trusted remediation actor produces a fix. Central can reproduce and validate it. The fix is narrow. The licensing checks out. Publishing under a new coordinate would make downstream remediation much harder.

What should the version be?

One option is to publish the next patch version:

That has the cleanest sorting behavior, but it consumes the maintainer's next normal version. If the maintainer later returns, we have blurred the line between an emergency remediation and an ordinary maintainer release.

Another option is to put the remediation actor in the version:

That is visible, but it creates a vendor-label race inside a legacy namespace. We do not want Central to become a place...