40,000 CVEs, NIST Limits Detailed Analysis

In March 2024, the US National Institute of Standards and Technology (NIST) analyzed 199 of the 3,370 CVE records it received. The CVE Program had already given each vulnerability a common identifier.

The CVE Program can distribute identifier assignment; NIST, vendors and defenders must still spend scarce capacity validating flaws, establishing exploit context, locating exposed systems, guiding repairs and checking whether those repairs took hold.

The CVE Program scaled naming before anyone scaled interpretation

The CVE Program’s common identifiers let researchers, vendors and operators refer to the same vulnerability without reconciling competing names. MITRE’s program had become a distributed reporting system by 2025: CyberScoop counted 413 organizations reporting entries. The CVE Program recorded more than 40,000 entries in 2024, bringing the cumulative total above 270,000. Distributed assignment is a strength, not a failed part of the system.

An identifier establishes that participants can discuss a flaw. It does not establish whether an attacker can exploit it, whether a particular organization runs the affected code, or whether an available patch has reached that organization. NIST’s CVE enrichment workflow requires a different input: analytical time applied after a record arrives.

That distinction became measurable in March 2024. NIST analyzed 199 of the 3,370 CVEs it received that month and cited insufficient interagency support. After a 2024 funding lapse, its backlog grew; by July 2025, MIT Technology Review reported more than 25,000 vulnerabilities awaiting analysis, roughly ten times the previous high in 2017. Neither count says that CVE assignment stopped. Together, they show why a growing registry could no longer imply equally prompt analysis of every entry.

NIST made analytical attention a risk decision

In April 2026, NIST narrowed detailed National Vulnerability Database analysis to flaws involving critical software, federal systems or active exploitation, including entries in CISA’s Known Exploited Vulnerabilities catalog. NIST also said it would review requests for detail on vulnerabilities outside those priorities. It did not announce that non-priority flaws would lose their CVE IDs or that no exception could receive analysis.

CISA had already supplied one operational distinction. Its Known Exploited Vulnerabilities catalog identifies flaws known to be exploited and directs federal agencies to patch cataloged vulnerabilities within prescribed timeframes. A CVE names a flaw; a KEV listing adds evidence of attacker use and a response obligation for those agencies. NIST’s criteria add other reasons to devote attention, including the importance of the software and its use in federal systems.

Those criteria also leave a judgment problem. Known exploitation is strong evidence of urgency, but the absence of a KEV listing does not prove that an exposed system is safe. NIST’s request process leaves room for cases its standing categories miss. The supplied coverage does not report comparable post-policy throughput, backlog or patch-adoption results, so it cannot establish yet whether NIST’s selection has made high-consequence analysis faster.

Faster exploits shorten the useful life of an untriaged record

Anthropic researchers said their Mythos Preview model could turn publicly disclosed vulnerabilities into working exploits in hours rather than weeks. That is a claim about the model’s demonstrated capability, not a measured conversion time for every public flaw. It nevertheless changes the decision facing a defender with a newly disclosed, reachable vulnerability: waiting for a uniformly complete database entry may consume much of the time available to patch or isolate the system.

Defenders need to keep two signals separate. CISA’s KEV catalog records known exploitation; a model’s ability to produce an exploit indicates potential speed, not proof that attackers are already using one. A vendor shipping a fix, in turn, does not establish that an operator has installed it. A useful triage decision records which signal justified urgent action and which evidence remains missing.

AI increases discovery capacity and tests repair capacity too

Anthropic and its Project Glasswing partners illustrate how quickly candidate volume can grow without producing a comparable count of repaired systems. Reuters reported Anthropic’s figure of 5,500 verified vulnerabilities found from April through October 2026. Glasswing partners reported more than 129,000 findings from April through July, over 33,000 rated critical or high severity. The reporters, periods and terms differ. The supplied record does not establish how those sets overlap, how many findings received CVEs, or how many fixes reached deployed software.

OpenAI offers an important counterexample to the idea that automation only adds to the queue. It described an AI-assisted pipeline that validated and patched 948 Linux local-privilege-escalation vulnerabilities, at $1.2 million in API costs. That is downstream work, not just detection. The API bill is not a complete accounting of review, integration or deployment, and a produced patch is not evidence that every affected operator has adopted it.

Vendors, maintainers and operators pay for different stages of that work. A vendor can publish a fix while an operator bears the cost of finding affected installations and changing them. For high-consequence decisions, an auditable human review should preserve why a finding was accepted, why one system took priority, and who confirmed the repair. Automation can reduce investigation effort without making accountability optional.

An exposed system, not a CVE, is the unit a defender can protect

Socket’s account of the Axios npm compromise makes the inventory problem concrete. Attackers introduced a malicious dependency into specific releases of a package reported to receive 100 million weekly downloads. That download count describes distribution, not the number of compromised installations. An operator needed to know which releases its applications actually used. The incident also shows why security work cannot be organized around CVE records alone: a compromised package release demands a deployment response whether or not a vulnerability identifier supplies the starting point.

At the other end of the scale, attackers exploited critical flaws in three internet-connected refrigerator-controller models in a hack affecting roughly 700 European supermarkets. Claroty and CISA flagged the models’ vulnerabilities, but the affected stores were defined by the controllers they had deployed and exposed. Product identity, reachability and the ability to replace or repair those controllers determined the work.

If vendors and operators can carry exploit evidence, affected-version details and repair status from disclosure to deployment, NIST can concentrate its analysis without asking the CVE registry to become smaller. NIST received 3,370 named flaws that March. For an operator with an exposed system, the final check is whether it still runs the vulnerable code.