NIST Analyzed 199 of 3,370 CVEs in March 2024

In March 2024, the US National Institute of Standards and Technology (NIST) analyzed 199 of the 3,370 Common Vulnerabilities and Exposures (CVE) records it received. That year, 413 organizations reported more than 40,000 CVEs. The system kept naming security flaws while the federal database built to explain them fell behind.

Those counts describe different jobs. An identifier lets a vendor, researcher, government agency, and software operator refer to the same reported flaw. Analysis must establish enough about affected products, severity, and context to help someone decide what to do. A name can be assigned before that work is complete.

The common name scaled because identification was distributed

The CVE system began in 1999 to solve a coordination problem: separate parties needed a common reference for a reported vulnerability. MITRE maintains the program, but large vendors and other participating organizations can assign identifiers. That delegation helped the registry grow past 270,000 records without requiring MITRE to investigate every flaw before anyone could name it.

NIST’s National Vulnerability Database was built on the CVE List to supply a richer public reference. Its work is different from issuing an ID. An operator trying to find affected software needs product and version context; an operator deciding whether to interrupt a deployment needs to know whether the flaw is being exploited and whether the vulnerable component is present and reachable. A score alone cannot answer either question.

NIST’s shortfall did not appear overnight. By 2025, it was seeking contractors to address a backlog of more than 25,000 vulnerabilities, roughly ten times the previous high reported for 2017. NIST had attributed the weak March 2024 analysis count to insufficient interagency support; a funding lapse later that year contributed to the backlog behind its subsequent policy change. Adding analysts can help, but each record still requires coordination among reports, product definitions, patches, and corrections. The identifier can be distributed more easily than a trustworthy judgment about its operational meaning.

MITRE’s neutrality depends on a working correction path

MITRE’s 2025 funding episode tested the identifier layer without breaking it. MITRE said its funding had expired; CISA extended support and said there would be no lapse in critical CVE services. The extension kept the registry running and made its dependence on continued support visible.

Continuity alone does not settle trust. In 2019, VideoLAN disputed a reported VLC issue, saying it lay in a third-party library fixed more than 16 months earlier, and alleged that MITRE had not checked the underlying claim. VideoLAN’s dispute shows what an affected maintainer needs when a public classification is wrong or stale: a way to trace the source, contest the description, and have a correction reach the people who rely on it.

MITRE can maintain the common name while NIST, CISA, vendors, and operators make different judgments about urgency. If a machine-assisted ranking becomes a patch order, the institution issuing that order must make its evidence and appeal path legible; a neutral identifier cannot carry responsibility for a decision someone else made.

NIST made the order of analysis explicit

In April 2026, NIST narrowed detailed NVD analysis toward CVEs in CISA’s Known Exploited Vulnerabilities Catalog and flaws affecting critical software, federal systems, or assets under active exploitation. NIST did not announce that vendors and other participants would stop assigning CVE identifiers. It changed which records would receive detailed analysis.

CISA’s known-exploited catalog supplies one reason for priority: it identifies flaws attackers are using, and CISA requires federal agencies to remediate listed vulnerabilities within prescribed timeframes. CISA later shortened the deadline for the most critical federal vulnerabilities to three days, citing hackers’ use of AI. An exploitation signal gives a particular set of operators a deadline.

Prioritizing known exploitation is an improvement over treating every high-severity label as an equally urgent repair order, but it leaves gaps. A flaw need not appear in the catalog to be dangerous, and a federal priority need not describe a private operator’s exposure. NIST can set a public analysis order; each organization still has to determine whether it runs the affected software, where it is exposed, and what it can safely take offline. An operator cannot infer safety from an NVD record that has not been enriched.

AI makes a finding easier to produce than to trust

Developers are adding code to the review queue faster. A Stack Overflow survey found that 84% of developers used or planned to use AI tools in their workflows, up from 76% in 2024, while trust in AI accuracy fell from 43% to 33%. Companies have struggled to review the resulting volume of generated code. Security researchers can use related tools to find weaknesses in that code and in software that predates it.

Anthropic reported 5,500 verified vulnerabilities found from April through October 2026; its Glasswing partners reported more than 129,000 from April through July, including more than 33,000 rated critical or high severity. Those reported findings should not be treated as an equivalent number of new CVE entries or completed patches. They do show why verification cannot be left as an afterthought to discovery.

The same cheap search can send unverified work to someone else’s inbox. Google froze product-flaw submissions to its OSS Vulnerability Reward Program amid invalid AI-driven reports. Curl planned to end its HackerOne program after low-quality AI-generated reports burdened its maintainers. The bug-bounty verification problem exposes the cost that a finding count omits: someone must reproduce a claim, identify the affected version, rule out duplicates, and decide who owns the fix. An automated researcher that supplies only a plausible description transfers that work to the recipient.

Attackers face fewer delays as well. An analysis of AI-assisted exploit development cited a case of 30 minutes between a patch and an exploit and argued that traditional disclosure windows could become untenable for critical issues. That case is an argument about possible speed, not a measured interval for all vulnerabilities. It nevertheless explains why the time between a sound finding and an authorized response matters alongside the accuracy of the finding itself.

Proof has to reach the owner of the exposed asset

In October 2026, attackers compromised Internet-connected refrigeration controllers across about 700 European supermarkets, exploiting critical vulnerabilities in three controller models identified by Claroty and CISA. A public identifier could name each flaw. Claroty’s and CISA’s product findings could help identify the affected models. Neither step, by itself, could tell a supermarket operator which controllers were connected or who could isolate one without disrupting refrigeration.

Censys monitors internet hosts and their security status. Startups pursuing formal software verification, including &Truth, are trying to produce stronger evidence about software behavior. An operator must connect a credible claim about a flaw to the system it actually runs.

The handoff requires a reproducible finding, an affected product and version, evidence of reachability or exposure, a responsible owner, and a decision to patch, isolate, or accept risk. When a model helps make that assessment, preserving the evidence lets a human reviewer challenge the inputs and identify who approved the action.

A CVE number fits on a label. The decision lives beside a running refrigerator controller, with an operator who must decide whether to isolate it.