50,000 CVEs a Year: How to Prioritise When the Volume Keeps Doubling

The volume problem, in numbers

48,152 CVEs were published in 2025, about 132 a day. In 2026 the daily rate so far is over 280. No team reads that many advisories, so every programme already filters; the only question is whether the filter is deliberate. Year-by-year figures are on our CVE statistics page.

Why severity alone does not work

Of the 2025 CVEs that NVD's analysts have scored, 20.2% are critical and 30.0% high under CVSS v3. Half of everything scored lands in the two bands most policies call urgent. A rule like "patch all highs and criticals within 14 days" therefore asks for thousands of urgent changes a year, and a rule nobody can follow gets quietly abandoned.

CVSS measures how bad a vulnerability could be if exploited, not how likely that is. We cover the difference in CVSS vs EPSS.

The scoring gap

There is a second problem. 65% of 2025 CVEs had not been scored by NVD at the time of counting, up from 8% in 2023. NVD's analysis has not kept pace with publication since early 2024 (background in the NVD backlog explained). Many of those CVEs carry a score from the organisation that issued them, but a process that waits for NVD's own score is waiting on a queue that is not getting shorter.

How rare exploitation is

CISA's Known Exploited Vulnerabilities catalog added 245 CVEs in 2025. Against 48,152 published, that is about one in two hundred. Exploitation is concentrated, and it tends to cluster in edge devices, remote-access products and widely deployed server software.

A triage order that scales

1. Exposure first. Does the CVE affect a product you run, at a version you run? This one question removes most of the volume. Eleven thousand of 2025's CVEs came from issuers that specialise in WordPress; if you do not run WordPress, very few of them are yours.
2. Known exploitation next. Anything in the KEV catalog that matches your exposure goes to the top, whatever its CVSS score.
3. Likelihood after that. EPSS estimates the probability of exploitation in the next 30 days and separates the plausible from the theoretical.
4. Severity to order the rest. CVSS is useful once the list is short enough to act on.
5. Context per system. The same CVE matters more on an internet-facing service than on an internal batch job. Track stacks per application, so a fix can be scheduled where it matters first.

Where a tool helps

Steps 1 and 5 are where volume hurts most, because matching tens of thousands of CVEs a year against everything you run is mechanical work. That is what stack tracking is for: declare the products and versions each application runs, and only the CVEs that touch them reach you, with exploitation data alongside. Whatever tool you use, put exposure before severity. The volume is not coming back down.