50,000 CVEs in 2025, 70,000 in 2026: Why Prioritization Is the Real Challenge
Nearly 50,000 vulnerabilities were published in 2025. Forecasts point to 70,000 for 2026. And yet, fewer than 1% of them will actually be exploited. This is no longer a detection problem. It is a prioritization problem.
This article explains why the CVSS + EPSS pairing, now the de facto standard, is no longer sufficient to decide what to patch, and what a modern prioritization approach should combine to stay useful in 2026.
Twenty years doing this work by hand
Our take, after twenty combined years in offensive cybersecurity and inside CERT teams, is unambiguous: vulnerability management as it is practiced today is no longer sustainable. The volume is exploding, contexts multiply (a customer's stack, their technologies, their exposure), and a CVE that is critical for one organization can be completely irrelevant for another.
By repeating the same exercise every morning (opening fifteen sources, cross-referencing, ranking, producing a note for each client on what deserved their attention in the next 24 hours), patterns emerged. Which signals really matter, in what order, with what weighting.
CVSS asks a question, just not the right one
A recent weekly bulletin from France's national CERT (CERT-FR, 30 March 2026) listed 34 vulnerabilities classified as critical (CVSS > 9), of which just one had public exploit code. In other words, 97% of that week's "critical" had, at publication time, no proof of concept, no observed exploitation, and no operational urgency.
CERT-FR does outstanding work. The problem sits upstream. CVSS answers: "How theoretically severe is this flaw?". It does not answer: "Does it concern my environment, and is it being exploited right now?"
Two concrete examples illustrate the gap:
CVE-2026-20122 (Cisco SD-WAN Manager), CVSS 5.4
On paper, it is a medium: authentication required, "file overwrite", no direct RCE. A purely CVSS-based triage would have ignored this vulnerability (anything under 7.0 pushed to next month).
Yet CISA classifies it as actively exploited. Why? Because attackers love appliances that pilot hundreds, sometimes thousands, of SD-WAN routers inside a large group 😈. Real-world criticality far exceeds the theoretical score.
CVE-2025-48983 (Veeam Backup), CVSS 10.0
Veeam is the number-one target for ransomware operators: wiping backups before encryption is a central objective. A CVSS 10.0 on this component is supposed to trigger the Friday-night crisis meeting 🚨.
And yet this CVE sits at an EPSS of 0.24%. Why? A detail buried in the description: "by an authenticated domain user". The attacker needs a foothold in your Active Directory to exploit it. This CVE has never been exploited publicly, and no PoC or exploit has ever surfaced.
Bottom line: nearly 50,000 vulnerabilities published in 2025, roughly half tagged critical by CVSS, fewer than 300 actually exploited. Less than 1%.
What about CVSS v4?
CVSS v4 specifically introduced a Threat metric group with an Exploit Maturity indicator ("Attacked", "POC", etc.), precisely to address the criticism of a frozen score. That is a real conceptual improvement. But in practice, only ~34% of CVEs published in 2026 carry a v4 score, and major vendors like Microsoft, Red Hat, and Oracle keep publishing in v3.1. And even when a v4 score is published, the Threat metrics (designed to evolve after disclosure) are rarely updated, because the issuing CNAs do not republish their vectors. Most importantly, the v4 base score remains, by construction, context-free: it will never know whether the affected technology lives in your stack. v4 is a step in the right direction, but it does not change the nature of the problem.
EPSS fills part of the gap, but not all of it
EPSS (Exploit Prediction Scoring System) predicts the probability of exploitation within 30 days. On paper, that is exactly what we need. In practice, three limits emerge quickly:
Black box. When a CVE jumps from 0.4% to 20% in 48 hours, no one knows why. It is hard to justify a patching decision to a customer or to your team based on an opaque signal.
Limited predictive reliability. Predicting exploitation is intrinsically hard, and the score reflects that. A probabilistic score alone cannot carry a decision: it must be cross-checked with factual signals.
Structural bias. EPSS relies on telemetry that is overwhelmingly North American, and it evaluates a vulnerability all the better when its attack surface is visible on the open internet. Concrete consequence: across the 45 CVEs reported on Stormshield's own code (a French firewall certified by ANSSI), none has ever exceeded 4% EPSS. Not because the risk is zero, but because EPSS is looking elsewhere.
Volume explodes, time-to-exploit contracts
By mid-2026, around 23,000 CVEs have already been published since January, +32% compared to the same period in 2025. Some forecasts point to 70,000 CVEs by end of 2026 (Jerry Gamblin, Cisco Threat Detection & Response), compared with 49,972 in 2025. And that figure predates the arrival of new AI-assisted vulnerability discovery tools (Claude Mythos & Co), still largely absent from current forecasts.
The real problem has shifted: finding vulnerabilities is no longer the bottleneck. The bottleneck is deciding which ones to patch first, before they get exploited. And the unit of time has changed. In 2025, we talked in days before exploitation. In 2026, we talk in hours. According to Zero Day Clock, the median delay between publication and the availability of exploit code has dropped from around 20 days to less than 20 hours. Attackers no longer have the politeness to wait until the end of the weekend.
The real challenge becomes clear: not finding more CVEs (there are already far too many), but deciding which ones deserve your two hours of patching this week. And that is precisely what existing approaches do not help with.
What good prioritization looks like
Useful prioritization cannot rest on a single indicator. It has to produce a score that recomputes continuously, by combining several categories of signals:
- Active exploitation: CISA KEV, CERT reports, private feeds (Shadowserver, Telegram, etc.)
- Exploit availability: ExploitDB, Metasploit, GitHub PoCs, Nuclei templates
- Statistical probability: EPSS, used as a complementary signal, never alone
- CERT advisories and vendor bulletins
- Environment context: is the affected technology in your asset inventory?
- Sightings: is the vulnerability getting significant mentions on social media?
Done well, this score evolves in real time: a CVE at 21/100 today can move to 60/100 tomorrow if a PoC is published on GitHub, then to 95/100 once active exploitation is identified. That is precisely the dynamic that CVSS lacks, since it is frozen at publication.
If this picture matches your day-to-day (too many CVEs, too little time, too few signals to decide), that is exactly the question that pushed us to build SYRN. You can try it for free.