VULNpocalypse
HighEcosystem changeOngoing

NVD stops enriching most CVEs: your scanner’s severity data now has gaps

Since 15 April 2026 NIST no longer adds severity scores or product data to most new CVEs. Tools that match on NVD data miss or misjudge risk.

Published
Updated
Exploitation
Not applicable

What happened

On 15 April 2026, NIST moved the National Vulnerability Database to a risk-based enrichment model. Every CVE is still added to the NVD, but NIST now only enriches three groups with its own analysis:

  • CVEs in CISA’s Known Exploited Vulnerabilities (KEV) catalogue,
  • software used by the US federal government,
  • “critical software” as defined under Executive Order 14028.

Everything else is marked “Not Scheduled”. Backlogged CVEs published before 1 March 2026 were moved to “Not Scheduled” in batches. NIST also stopped adding its own severity scores and relies on the scores from the CVE Numbering Authority that published the CVE (Help Net Security; The Hacker News).

NIST cited a 263% increase in CVE submissions between 2020 and 2025. It enriched nearly 42,000 CVEs in 2025, 45% more than any previous year, and still could not keep up. You can ask for a specific CVE to be enriched by emailing nvd@nist.gov.

This is the end point of a backlog that began on 12 February 2024, when NVD processing first slowed (VulnCheck).

Why developers should care

“Enrichment” is the part tools use: the CVSS score, and the CPE entries that say which products and versions are affected. Without it:

  • Version matching fails. Scanners that match your software against NVD CPE ranges, such as OWASP Dependency-Check, cannot match CVEs that have no CPE data. They miss real issues silently.
  • Severity becomes inconsistent. Scores now come from whichever organisation filed the CVE, and some file without one. Dashboards that sort by “NVD CVSS” put unscored criticals at the bottom.
  • Policy gates break. “Fail the build on CVSS 9 or above” passes builds that contain unscored critical bugs.

The NVD has not shut down. It still lists every CVE, and it still fully analyses the ones most likely to matter, starting with those known to be exploited.

Am I affected?

Check where your tools get their data. Then run an ecosystem-native scanner next to your current one and compare the results:

bash
# Scan a repository against OSV.dev, which aggregates ecosystem advisories (GHSA, PyPI, Go, RustSec and others)
osv-scanner scan source -r .

# Language-native audits backed by advisory databases rather than NVD CPE matching
npm audit
pip-audit

If the OSV-backed scan finds issues your current tool misses, your current tool depends on NVD enrichment.

What to do now

  1. Use ecosystem advisory data for matching. OSV.dev, the GitHub Advisory Database, and distribution security trackers describe affected versions in each package manager’s own terms, and do not depend on NIST.
  2. Prioritise with exploitation signals, not scores alone. Check whether a CVE is in CISA KEV, and what its EPSS exploit-probability score is:
bash
# Is this CVE known to be exploited? (CISA KEV)
curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq -r '.vulnerabilities[].cveID' | grep -Fx CVE-2026-109618

# How likely is exploitation in the next 30 days? (FIRST EPSS)
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-109618" | jq '.data'
  1. Fix your build gates. Treat “no score” as “needs triage”, not “low”. Fail on anything in KEV regardless of score.
  2. Record where each severity came from (NVD, the CNA, GHSA, or your own triage), so people know how much to trust it.

Why this is part of the Vulnpocalypse

The Vulnpocalypse is a volume problem, and this is the clearest sign of it: the public institution that scored vulnerabilities for everyone decided it can no longer score them all. It happened eight days after the Claude Mythos Preview announcement, in the same weeks that AI-driven discovery took off. From here on, prioritisation is your job, or your tooling’s.

Sources