Vulnerability Overload in 2026: Why Over 100 New CVEs a Day Broke Patch Everything, What CVSS, EPSS and the KEV Catalog Each Actually Tell You, and How to Decide What to Fix First
- Internet Pros Team
- September 25, 2026
- Networking & Security
Every vulnerability scanner eventually produces the same report: hundreds of findings, dozens marked Critical, and a team with time to fix a handful this week. The old rule of patching everything rated High or Critical stopped being possible years ago. More than 40,000 CVEs were published in 2024 and close to 48,000 in 2025, well over a hundred a day. The question is no longer whether you can patch it all. It is how you decide which few things matter first, and which scores to trust when you do.
Why the Firehose Got Worse
Three changes turned a steady flow of security advisories into a flood.
- More organisations issue CVEs. There are now hundreds of CVE Numbering Authorities, including the Linux kernel project, which assigns an identifier to almost every bug fix that could have security impact. More coverage is good, but it multiplies the count.
- The central database fell behind. From early 2024 the US National Vulnerability Database stopped keeping up with enrichment, the step that adds severity scores and affected product lists to each CVE. Tens of thousands of records sat unanalysed, and in 2025 NIST marked older backlog entries as deferred. Scanners that rely on NVD data quietly report less than they should.
- The system itself looked fragile. In April 2025 the government contract that funds MITRE to run the CVE programme came within hours of lapsing before a last-minute extension. The scare pushed others to build alternatives: the EU Vulnerability Database run by ENISA and the GCVE initiative from Luxembourg’s CIRCL.
Meanwhile attackers got faster. Several threat intelligence studies found that the average time between disclosure and first exploitation fell to days, and a growing share of flaws are exploited before a patch exists at all.
Severity tells you how bad it would be. Exploitation tells you whether it is happening. Only your own asset list tells you whether it can happen to you.
Three Scores, Three Different Questions
Most prioritisation mistakes come from treating one number as if it answered every question. The three signals in common use measure different things.
| Signal | What it answers | Where it misleads |
|---|---|---|
| CVSS (FIRST, now version 4.0) | How severe is this flaw in the worst reasonable case? | A 9.8 that nobody exploits outranks a 7.5 that ransomware gangs use every day |
| EPSS (FIRST, version 4 since 2025) | How likely is exploitation activity in the next 30 days? | A probability across the whole internet, not a statement about your network; it lags brand new CVEs |
| CISA KEV catalog | Is there reliable evidence this is being exploited in the wild right now? | Confirmed cases only, so it is short by design and will never list everything dangerous |
Used together they are powerful. Research on exploitation data consistently finds that only a small fraction of published CVEs, commonly estimated in the low single digits percent, are ever exploited. A queue built on CVSS alone spends most of its effort on the rest.
What CVSS 4.0 Changed, and What It Did Not
CVSS 4.0, released in late 2023, split the score into layers: a Base score for the flaw itself, a Threat layer that lowers the score when no exploit is known, and an Environmental layer where you describe your own system. It also added attack requirements and supplemental fields such as whether exploitation can be automated.
The catch is that almost everyone still publishes and consumes only the Base score, which by definition ignores both real-world threat and your environment. CVSS 4.0 can express risk properly, but only if you, or your tooling, fill in the parts the vendor cannot.
Context Is the Part Only You Can Supply
No public score knows that the vulnerable server is the one facing the internet, or that the vulnerable library is installed but never loaded. That context usually changes the answer more than any score.
Four Questions That Reorder the Queue
- Is it reachable? A flaw on an internet-facing VPN, firewall or web server is in a different class from the same flaw on an isolated workstation.
- Is the vulnerable code actually used? Software vendors increasingly publish VEX statements saying a component is present but not exploitable in their product. Treat them as evidence, not a guarantee.
- What does the asset hold? Identity systems, backups, payment and remote access tools deserve a shorter deadline than a lobby display.
- Is there a mitigation now? If a patch needs a maintenance window, a configuration change, a firewall rule or disabling a feature can close the door today.
CISA and Carnegie Mellon formalised this thinking as SSVC, a decision tree that combines exploitation status, exposure, whether exploitation is automatable and mission impact into four outcomes: Track, Track*, Attend and Act. It is a useful template even if you never adopt the full method.
A Practical Order of Operations
For a small or mid-sized business, a simple tiered policy beats a sophisticated one nobody follows.
- Tier 1, within days: anything in the KEV catalog that affects an internet-facing system or a security, identity or remote access product. US federal agencies are held to deadlines of weeks for KEV items; attackers usually move faster than that.
- Tier 2, within two weeks: KEV items on internal systems, and anything with a high EPSS score that is reachable from outside.
- Tier 3, normal patch cycle: high CVSS findings with low exploitation likelihood, handled in monthly updates.
- Tier 4, documented acceptance: findings that are unreachable or mitigated, recorded with a reason and a review date instead of being silently ignored.
Two habits make the tiers work. First, keep an accurate inventory: you cannot match a KEV entry against a device you did not know you owned, and forgotten appliances at the network edge are exactly what attackers scan for. Second, automate the boring majority. Operating system, browser and office updates should roll out on their own so that people spend their attention on the exceptions.
Finally, do not depend on a single data source. The NVD slowdown showed that a scanner is only as good as the feed behind it. Tools that combine vendor advisories, KEV, EPSS and alternative databases give a truer picture than any one list.
The Bottom Line
The volume of vulnerabilities will keep rising, because more software is being written, more of it is being examined, and AI tools are making both finding and exploiting bugs cheaper. Trying harder at patch everything is a losing strategy. Deciding deliberately, using severity, exploitation evidence and your own context, lets a small team fix the right handful of things first and show why the rest can wait.
Drowning in scanner findings or not sure what is exposed on your network? Talk to Internet Pros. We inventory your systems, set up patching that runs on its own, and build a prioritised plan so the vulnerabilities attackers actually use get fixed first.
