4 MIN READ
Picture the modern CVE database. Around 240,000 entries now, with roughly 28,000 new ones added in 2025, up from 22,000 in 2024. Most security teams cannot patch at the rate the CVEs come in, and the database is now doing the work a breach vector used to do. Here is what the 2026 numbers look like, and what to do when the patching cannot keep up.
The size of the problem. A mid sized enterprise typically has 1,000 to 10,000 assets in scope, with each asset carrying 5 to 20 CVEs at any time, and a typical security team closing 10 to 50 CVEs per week. The patching program processes only a fraction of what the database produces each month, and the gap widens every cycle.
The numbers that show the problem
Four numbers worth holding onto. First, the running total in the CVE database sits at 240,000, growing fast each year for the last half decade, and that figure does not include the duplicates the NVD has not deduplicated. Second, 28,000 new CVEs were added in 2025, up by more than a quarter from 2024, and the growth rate is still accelerating. Third, the mean time to patch the critical CVE in a typical mid sized fleet sits at 70 days, up from around 50 days in 2024, so the patching program is running slower, not faster. Fourth, a meaningful share of CVEs stays unpatched at any given time, which works out to dozens or hundreds per asset in a typical deployment. Add them up and the patching program cannot keep up.
What the patching approaches fail at
Three approaches that have all been tried. Patch everything: a team tries to close every CVE, works 80 hours a week, burns out, quits, and the program collapses. Patch the criticals: focus on CVSS 9+ and CVSS 7+, ignore the rest, and watch the medium and low CVEs get exploited, because the score never stopped anyone with a working exploit. Patch the exploitable: focus on CVEs with a known exploit, ignore the rest, and miss the new exploit CISA has not catalogued yet. None of the three approaches escapes the same pattern, because the underlying problem is volume, not selection.
What to do when the patching cannot keep up
Three moves that actually hold up. Risk based prioritisation, where work is ordered by exploitability (the CISA KEV list, the known exploit in the wild), and a security team closes the CVEs that get weaponised first while the rest sit. Compensating controls, where network segmentation, an application allow list, or behaviour monitoring is applied to every CVE that goes unpatched in the next 90 days, and the impact gets contained while the queue catches up. Virtual patching, where a WAF or IPS rule blocks the exploit of a CVE that sits in the queue, buying the days or weeks needed to do the real work. Teams that layer all three end up ahead of the curve.
The bottom line
Risk based prioritisation, compensating controls, virtual patching. That is the working answer to a CVE volume nobody can patch flat out. The patching program that pretends the volume will slow down is the program that finds out the slowdown came from the attacker, not the database.
Sources & Further Reading
All claims in this article are sourced from primary documentation, vendor advisories, and reputable security researchers.
Spotted an error? Email the editor. Corrections are issued with a visible correction note.
Editorial standards. Every article on humanrequired.org is reviewed by a human editor before publication. AI may assist with drafting or research; final editorial control is human. Read the full standards.
