CVE-2025-Fatigue Is Real: How the NVD Backlog Crisis Is Breaking Enterprise Patch Management

By | Monday, March 16, 2026

The Backlog That Wouldn’t Clear

In February 2024, something broke at the National Vulnerability Database. Not catastrophically, not in a way that made headlines, but in a way that mattered enormously to anyone responsible for keeping systems secure. The database began accumulating a processing backlog. By mid-2025, when NIST formally acknowledged the problem through an official statement, the organization confirmed what security teams had already learned the hard way: they still had not fully cleared that backlog. Thousands of newly published CVEs sat in the queue without enrichment data—no CVSS severity scores, no detailed vulnerability descriptions, no actionable context. Just empty records.

CVE-2025-Fatigue Is Real: How the NVD Backlog Crisis Is Breaking Enterprise Patch Management
CVE-2025-Fatigue Is Real: How the NVD Backlog Crisis Is Breaking Enterprise Patch Management

This was not a minor inconvenience. By Q3 2025, tracking data published by organizations like Anchore and VulnCheck showed that the NVD had more than 18,000 CVEs awaiting full analysis. That number represented vulnerability disclosures that enterprises could not properly assess, prioritize, or defend against. Patch managers found themselves staring at vulnerability lists with incomplete information, unable to make confident decisions about where to focus limited remediation resources.

The irony is sharp. The systems we built to help us manage vulnerability risk had themselves become a source of risk. The institution meant to provide clarity was providing silence.

Illustration for CVE-2025-Fatigue Is Real: How the NVD Backlog Crisis Is Breaking Enterprise Patch Management
Illustration for CVE-2025-Fatigue Is Real: How the NVD Backlog Crisis Is Breaking Enterprise Patch Management

The CVE Explosion and What Created It

Before examining why the backlog happened, you need to understand the scale of what the NVD was trying to process. In 2024, organizations published 40,009 CVEs. That is not a typo. In a single year, the vulnerability community disclosed more than 40,000 individual vulnerabilities. For context, 2023 saw 28,961 CVEs published, which was already a significant year. The jump from 2023 to 2024 represented a 38% increase in vulnerability disclosures.

This explosion did not happen by accident. More researchers are finding vulnerabilities and responsibly disclosing them. Open source adoption has created a wider attack surface to discover. Supply chain vulnerabilities have become more visible and better tracked. The vulnerability community itself has become more sophisticated at finding and reporting issues that previous generations might have missed.

None of this is bad. More transparency about security weaknesses is fundamentally healthier than fewer disclosures. But it created a volume problem that the NVD’s infrastructure was not designed to handle. The organization had grown accustomed to processing somewhere between 20,000 and 30,000 CVEs annually. Suddenly it faced nearly 50% more work, and the staffing and systems to do that work had not scaled accordingly.

Why This Breaks Patch Management at Scale

Here is where theory meets practice. Security teams rely on CVSS scores and detailed vulnerability metadata to make triage decisions. When you have thousands of vulnerabilities hitting your environment in a given week, you cannot treat them all as equally urgent. You need context. You need to know whether a given CVE affects your specific technologies. You need severity scoring that reflects actual risk. Without that enrichment, patch management becomes guesswork.

A 2025 Tenable Research report examined 60% of the breaches in their dataset and found something unsettling: in those cases, the vulnerability being exploited had a patch available for more than 30 days before the attack succeeded. Thirty days is not a tight timeline. Most organizations with competent patch management processes should be able to deploy critical patches within a month. The question becomes: why were they not? Part of the answer is almost certainly that vulnerability data was incomplete or delayed, making it impossible to properly triage which patches actually mattered.

When the NVD backlog prevented teams from understanding which vulnerabilities were severe and which were minor, patches that should have been deployed sat waiting for clarification. By the time enrichment data arrived, the attack had already landed.

The Stopgap Measure and What It Reveals

CISA understood the problem. In 2024, the organization launched the Vulnrichment program, designed as a temporary bridge to fill the gap while the NVD worked through its backlog. The concept was straightforward: CISA would accept data directly from CVE Numbering Authorities (CNAs) and publish enriched records separately, allowing teams to access useful metadata even when the NVD had not yet processed the vulnerability fully. You can examine the technical implementation and access the data through the CISA Vulnrichment GitHub Repository.

This was the right call operationally, but it was also a symptom of institutional failure. The United States government had to create a secondary system to do what the primary system could no longer accomplish in time. CISA’s team showed real skill in executing the Vulnrichment program, but its existence acknowledged that the original architecture had broken under real-world load.

For those of us who have been working security operations for years, this pattern is familiar. When the primary system breaks, you layer on compensating controls. You build workarounds. You patch the process rather than the underlying problem. Vulnrichment works. It has genuinely helped teams access data they needed. But it is a solution that validates the problem. We should not need a stopgap if the main system were adequately resourced.

To understand the current state of NVD operations and what NIST has planned, you can review the official NVD Backlog Status and NIST Statement, which provides transparency about the backlog situation and the path forward.

What Comes Next: The Forecast

Looking ahead, a few things seem clear. First, the CVE publication rate is not going to decrease. If anything, it will keep climbing as vulnerability research sophistication increases and supply chain visibility improves. The 40,000 CVEs published in 2024 will probably not be the high water mark. Second, the NVD’s current architecture is not designed to handle this scale sustainably. NIST has acknowledged the backlog and is working on improvements, but those improvements will take time.

What is less certain, and where the speculation begins, is whether organizations will accept the new reality or demand systemic change. Enterprises have historically relied on the NVD as the authoritative source for vulnerability metadata. If that source cannot deliver information in time to matter for active defense, security teams will turn to alternative sources. They already are. Vendors like Tenable, Qualys, and others have built their own vulnerability enrichment capabilities. Smaller organizations join threat intelligence services. The consequence is a fragmented ecosystem where different teams have different data about the same vulnerabilities.

This fragmentation is not ideal, but it may be the realistic future. Centralized systems optimized for completeness and accuracy cannot keep pace with distributed systems optimized for speed and context. The NVD will likely become one input among several, rather than the single source of truth it once was.

The Practical Reality for Your Organization

If you are responsible for patch management, the lesson from this backlog crisis is simple: stop waiting for perfect data. It cannot arrive in time. Build your processes to work with incomplete information and adjust as enrichment data becomes available. Use multiple sources for vulnerability context. Invest in tooling that can synthesize data from the NVD, CISA Vulnrichment, vendor advisories, and threat intelligence feeds. Treat your patch pipeline as a dynamic system that gets smarter over time, not a static process that waits for the authoritative answer.

The CVE-2025-Fatigue is real, but it is not a reason to surrender. It is a signal to adapt.

What approaches have you found effective for managing vulnerability data when official sources lag? I would welcome hearing from practitioners who have developed effective strategies for this environment. The solutions that work in the field often teach us more than theory ever can.