Since February 12, 2024, the National Vulnerability Database has been publishing far fewer enriched CVE records than it receives, and the gap has never fully closed. NIST's own status updates admitted a "temporary" slowdown tied to a new contract and "an increase in software and, therefore, vulnerabilities," but more than two years later, tens of thousands of CVEs still sit without CVSS scores, CPE data, or CWE classifications. In 2024 alone, over 40,000 CVEs were published — a new annual record and roughly 40% more than 2023's previous high of 28,961. Every one of those records needs analysis before most scanners can rank it. When the enrichment pipeline can't keep pace with submission volume, severity data arrives late or not at all, and vulnerability management programs built around "wait for the NVD score" start missing exploited flaws in production for weeks. Here's what the backlog actually looks like, why it happened, and what to do about it in the meantime.
What caused the NVD backlog?
The NVD backlog started when NIST drastically cut back CVE enrichment starting February 12, 2024, without a public explanation until weeks of community pressure forced a statement. NIST cited a new contract transition, budget constraints, and "a change in interagency support," alongside a genuine surge in vulnerability volume — CVE submissions had grown from around 25,000 in 2022 to nearly 29,000 in 2023 before jumping past 40,000 in 2024. Analysts also pointed to years of flat NVD funding despite an expanding CVE Numbering Authority (CNA) ecosystem: as of 2024 there were more than 350 active CNAs, each capable of publishing CVEs directly into the pipeline that NIST's small analysis team has to enrich. The result was a structural mismatch — submission volume kept climbing while the enrichment headcount didn't, and the queue of "Received" but unanalyzed CVEs (visible on NVD's own dashboard) grew from roughly 3% of the total catalog in early 2024 to over 50% by mid-2024, according to trackers like VulnCheck that began publishing daily backlog counts once NIST stopped commenting.
How large is the NVD backlog right now?
The backlog peaked at more than 18,000 CVEs awaiting analysis in mid-2024 and has fluctuated between roughly 6,000 and 20,000 unanalyzed records ever since, depending on which month's CNA submission surge NIST's contractors are working through. NIST brought in additional analyst support from Analygence in the spring of 2024 and told Congress it expected to be "caught up" by the end of fiscal year 2024 (September 30, 2024); that target slipped, and independent trackers still showed thousands of CVEs sitting in "Received" or "Awaiting Analysis" status well into 2025. The practical effect is a moving target: a CVE published on a Tuesday might get a CVSS score within 48 hours if it's high-profile, or sit unscored for six to eight weeks if it's a lower-visibility library. Security teams that gate patching decisions strictly on NVD's CVSS field are, in effect, running vulnerability management on a delay they can't predict in advance.
What does the backlog mean for CVSS scoring and triage?
The backlog means a large share of newly disclosed CVEs have no authoritative severity score at the moment they're disclosed, which breaks CVSS-threshold-based triage rules that most vulnerability management programs still run on. A policy like "patch anything CVSS 7.0 or higher within 30 days" is unenforceable for a CVE that has no CVSS field yet — teams either ignore it until NVD catches up, defer it to a manual review queue that never gets emptied, or fall back on whatever score the CNA itself supplied (CNA-supplied CVSS scores are optional and inconsistent in quality; some CNAs, like individual open-source maintainers, don't provide one at all). This is what pushed CISA to launch the Vulnrichment program in May 2024, adding its own CVSS, CWE, and CPE data to thousands of CVEs NIST hadn't processed. But Vulnrichment covers a subset of CVEs (largely those CISA judges relevant to federal risk), not the full catalog, so plenty of records — especially in niche open-source packages — still ship with no severity signal from any government source for weeks after disclosure.
Are attackers exploiting the gap between disclosure and enrichment?
Yes — exploitation timelines have compressed well below the NVD's enrichment lag, so unscored CVEs are frequently already weaponized before they get a CVSS number. Multiple threat intel firms, including Mandiant and GreyNoise, have documented time-to-exploit windows under five days for high-value CVEs in 2024, and CISA's Known Exploited Vulnerabilities (KEV) catalog has repeatedly added CVEs that were still sitting in NVD's "Awaiting Analysis" queue at the time they were added. That sequencing — KEV listing before NVD scoring — is the clearest evidence that severity-score latency, not exploit development time, is now the bottleneck in a lot of organizations' response process. A vulnerability management program that only escalates once a CVSS score lands is, by definition, always operating behind attackers who don't wait for NIST.
How should vulnerability management teams adjust their process?
Teams should replace "CVSS score present" as a triage trigger with signals that don't depend on NVD's enrichment pipeline: CISA KEV inclusion, EPSS probability-of-exploitation scores (updated daily by FIRST, independent of NVD), CNA-supplied severity where available, and reachability of the vulnerable code path in the actual deployed application. EPSS in particular is useful precisely because it's generated from exploitation telemetry rather than manual analyst review, so it's available the moment a CVE is published — no enrichment lag. Combining KEV status, EPSS, and reachability lets a team correctly deprioritize a "Received, no CVSS" CVE that has near-zero exploitation probability and no reachable call path, while still escalating an unscored CVE that's already in KEV or trending in EPSS. This is a shift from severity-first to exploitability-first triage, and it's the only approach that keeps working whether NVD is caught up or six weeks behind.
How Safeguard Helps
Safeguard's reachability analysis determines whether a vulnerable function in a dependency is actually invoked by your application's code paths, so a CVE with no CVSS score yet doesn't sit unranked — it gets prioritized (or safely deprioritized) based on real exploitability rather than a NIST queue position. Griffin AI, Safeguard's security reasoning engine, cross-references CNA data, EPSS, and KEV status the moment a CVE is disclosed, filling the gap left by delayed NVD enrichment with an internally generated risk signal instead of waiting on external scoring. Continuous SBOM generation and ingest give teams an always-current inventory of exactly which components carry a given unscored CVE, across every repo, without manual lookups. And when a fix is available, Safeguard opens an auto-fix pull request against the affected dependency automatically, so remediation doesn't have to wait for a CVSS number to justify the work.