Volume Is Not Risk: Making Sense of the “Vulnpocalypse”
According to the FIRST Exploit Prediction Scoring System (EPSS), only around 5% of all published CVEs are ever observed being exploited. The CISA KEV catalog grew meaningfully, from 1,239 entries at the end of 2024 to 1,484 at the end of 2025, but that is a rounding error against the tens of thousands of new disclosures.
The challenge lies in the massive triage bottleneck that the vulnpocalypse will create; the NVD fully analyzed only about 28% of newly disclosed CVEs in 2025, but not a proportional explosion of exploitable risk, according to the Zafran analysis. NIST itself confirms the strain: the agency reported a 263% jump in submissions since 2020 and is now triaging enrichment by risk tier rather than analyzing every CVE.
Why the raw number is exploding
It should be noted that the surge in CVEs is not a sign that software suddenly became dramatically less secure, rather, it is driven by three structural factors:
AI-assisted discovery
Autonomous bug-hunting is pointing frontier models at decades of legacy code. Models such as Anthropic’s Mythos and OpenAI GPT 5.5 are highly effective at surfacing latent stability bugs. However, volume is not risk: the Linux kernel alone now accounts for more than 5,800 CVEs because its CVE Naming Authority (CNA) assigns an identifier to nearly every bugfix, even where no security impact is demonstrated. The real-world exploitation rate across that set sits near zero (on the order of 0.02%). Finding a flaw and having it weaponized are very different events.
Changes in structural reporting
The discovery and cataloging infrastructure is catching up, inflating counts without changing actual exposure. This includes a roughly 449% year-over-year jump in GitHub Security Advisory volume and a large backlog of previously unassigned vulnerabilities finally being cataloged.
Product sprawl
The number of distinct products with tracked vulnerabilities has grown by orders of magnitude. More software simply means more CVEs. This also applies to code: as more code is written into existence by AI and coding agents, more bugs are also written into existence.
The real threat is speed, not volume
The metric that actually matters is speed. The window between disclosure and exploitation is collapsing from weeks to hours, and a rising share of exploitation now begins before a vendor patch is even public. In response, CISA recently retired its flat 14-day KEV remediation deadline in favor of a risk-based model that can demand action in as little as three days for the highest-risk combinations.
This is where AI Operational Excellence and proactive intelligence become mandatory. The TrendAI™ Zero Day Initiative™ (ZDI) exists to close this gap on the front end. Supported by more than 19,000 contributing researchers, TrendAI™ ZDI accounted for roughly 60% of the world’s coordinated disclosures in a 2023 independent tally, including 57% of critical-severity flaws, and turns those findings into protection that reaches customers an average of 115 days ahead of the vendor patch. When attackers weaponize zero-days against edge devices on day zero, pre-disclosure protection is no longer optional.
An action plan for security leaders
To weather what 2026 is set to bring, security programs must shift from counting raindrops to neutralizing the flood. Security leaders should be asking, “Are we still reporting CVE counts, or have we pivoted our metrics to exploitability?” The teams that succeed in 2026 will not be the ones who patched the most; they will be the ones who knew exactly what to patch first. The following best practices are recommended to minimize overwhelm and address vulnerabilities strategically:
Stop reporting raw CVE counts to the board
Raw numbers frighten without informing. Report the actionable slices and trends based on the data on hand.
Triage KEV-first, then EPSS
Confirmed exploitation is the sharpest filter available. Patch the top exploitability percentiles at zero-day urgency, and let the rest follow standard cadences.
Buy back time with virtual patching and containment
When exploitation outpaces the fix or a vendor patch does not yet exist, shielding vulnerable systems at the network or workload layer neutralizes the exploit path without waiting on a code change. Virtual patching and containment turn the disclosure-to-patch gap from an open exposure window into a managed one, and they matter the most for exactly the small set of actively exploited flaws that triage surfaces.
Invest in automation, not a bigger patch treadmill
Enrichment and triage loads are doubling while urgent live-system patching remains flat. Budget for intelligence that cuts through the noise.
Close the metadata gap
A large share of new CVEs arrive without complete severity or product data. Lean on exploitability intelligence rather than raw catalog fields.
About Author
