The CVE Crisis Isn’t Over: What Comes Next for Global Vulnerability Management

Last week, funding for the CVE program, the backbone of vulnerability identification around the world, nearly disappeared. MITRE, which manages CVE, announced that its funding had expired, and without an urgent intervention, new vulnerability identifiers would no longer be assigned.

CISA stepped in with emergency funding. That bought us 11 months.
But here’s the uncomfortable truth: we’re not in the clear. CISA itself is under budget pressure, and there’s no guarantee that support for CVE will continue after the current extension. Depending on how U.S. politics go, this entire crisis could come roaring back sooner than expected. The stopgap is only a temporary solution.

While not every cybersecurity process or tool strictly depends on CVE, it remains the central reference point for how most of the world coordinates vulnerability tracking. CVE identifiers are embedded in scanners, patch management systems, exploit frameworks, compliance tools, and security advisories. Even when organisations use internal databases or proprietary systems, they often map back to CVE IDs for correlation.

The loss or disruption of CVE wouldn’t halt all vulnerability management, but it would break many of the links that help tools, teams, and communities speak the same language. If CVE hiccups, the ecosystem shakes.

This isn’t just an American issue. CVE is baked into global security infrastructure. It’s the standard.

Which is why this near-miss should have everyone paying attention.

First, let’s not panic. The world existed before CVE. Vulnerabilities were tracked through mailing lists, security advisories, and independent databases.

If CVE disappeared tomorrow, those with resources would patch together alternatives. Open source communities and vendors alike would spin up identifiers, adopt existing secondary databases, or build new standards. In fact, some of that is already happening. The near-defunding spurred renewed interest in decentralisation and competing systems.

But there is a catch. Even if replacement systems emerge, they won’t be instant, they won’t be interoperable, and for a time, the world will have fragmented, inconsistent, and incomplete vulnerability tracking. That means slower response, more confusion, and greater risk.

The fallout wouldn’t just be technical. It would be organisational.

Compliance programs. Risk models. Procurement processes. All rely on CVE.

The truth is, the CVE system had deep cracks long before this funding cliff. Security veterans have been sounding the alarm for over a decade.

In the Extended Vulnerability Community discord server, which you can join here, Jericho, a cybersecurity social media staple, linked to talks previously given at various conferences about the issues with CVE. You can view slides for those talks, and others, here.

To summarise some of the issues that Jericho points out:

• CVE coverage is incomplete. Thousands of vulns never get an ID.
• Its abstraction model leads to wildly inconsistent stats.
• Vendor bias, publication bias, and measurement errors corrupt the dataset.
• Analysts are stretched thin. Prioritisation is opaque. The tools are ageing.

Meanwhile, everything from public policy to product comparisons relies on CVE data, often without understanding these caveats.

Vulnerability databases are the foundation of cybersecurity. But the foundations are less than solid.

Arachne Digital’s focus is on cyber threat intelligence (CTI) and threat-informed defence. Understanding how hackers hack and planning your defences accordingly can help improve your organisation’s security. Having CTI doesn’t make us, or you for that matter, immune to the problems above, but it does mean we look at vulnerabilities a little differently.

We care less about the ID and more about the context, such as who’s exploiting it, how, and against whom. Mapping vulnerabilities to real-world attacker behaviour helps teams prioritise even when the database is incomplete or flawed.

That’s not a fix for the system. But it’s a way to operate despite its shortcomings.

The near-collapse of CVE funding should make it clear that centralising critical infrastructure into a single point of failure is risky. We’ve seen this movie before in other domains, whether it’s DNS, certificate authorities, or cloud hosting. Monocultures might be efficient, but they’re brittle. If we want long-term resilience, we need decentralisation, not just as a fallback, but as a design principle.

We don’t need one global monolithic vulnerability database. We need:

• Decentralised identifiers that are interoperable
• Open standards that any org can adopt
• Transparent processes with clear abstraction rules
• Collaborative maintenance across sectors
• Recognition that context matters (threat actor usage, affected industries, etc.)

And above all, we need resilience. A single point of failure for global vulnerability tracking is a risk in itself.

Here’s what needs to happen:

• Policy reform: Governments that depend on CVE should commit to multi-year, multi-stakeholder funding.
• Open source support: Fund and use open VDBs that publish their methodology and accept contributions.
• Shared governance: Build standards bodies around vulnerability identifiers like we have for DNS or the web.
• Security community involvement: Treat VDB curation like a public good. Reward it. Incentivise it.
• Decentralise carefully: Support efforts to create redundant, compatible alternatives that can sync or interoperate.

Arachne Digital believes in better defences come from good CTI, open source tools, and shared infrastructure. We’re committed to being part of the solution, but no one group can fix this alone.

Solving this doesn’t fall on one entity. Governments must fund and legislate long-term support for shared security infrastructure. Vendors need to publish vulnerability information more transparently and support open standards. Researchers should be empowered to contribute without facing legal threats. And the security community at large, from startups to nonprofits, should see vulnerability tracking as shared civic infrastructure, not just a commercial feature. If we treat VDBs like a commons, they’ll serve us like one.

Encouragingly, some in the community are already moving. We’re seeing open source initiatives, distributed identifier experiments, and new tooling emerge, not to replace CVE out of spite, but to build redundancy, transparency, and innovation into a system that desperately needs it. These efforts deserve real support, funding, adoption, and collaboration, not just when CVE falters, but now, when we still have time to build something stronger in parallel.

The story of CVE isn’t just about a funding crisis, it’s about the fragile systems we’ve come to rely on, and the urgent need to rethink how we manage risk at a global scale. This is a moment to reflect, yes, but more importantly, it’s a moment to act. We can’t afford to treat vulnerability management as background noise anymore. It’s infrastructure. It’s strategic. And it’s time we treated it that way.