The National Vulnerability Database published 6,517 CVE records in 2016 and 84,553 in 2026 through 18 October, against 49,972 in all of 2025. Volume has grown about thirteen times in a decade. Against that, CISA added 264 entries to its exploited list in 2026, so raw volume cannot be a patch list.
Method
We queried the NVD CVE API (version 2.0) on 19 October 2026 and read the total result count for each window of 90 days or less, using the published date of each record. We summed windows to get a count per calendar year, from 1 January 2016 to 18 October 2026. We did not exclude rejected records. The counts are therefore all records NVD assigned a published date in that year, and a stricter filter would give slightly lower numbers. The NVD API also rate limits requests, so we spaced them out.
The yearly counts
| Year | CVE records published |
|---|---|
| 2016 | 6,517 |
| 2017 | 18,113 |
| 2018 | 18,154 |
| 2019 | 18,938 |
| 2020 | 19,222 |
| 2021 | 21,950 |
| 2022 | 26,431 |
| 2023 | 30,949 |
| 2024 | 40,704 |
| 2025 | 49,972 |
| 2026 (to 18 October) | 84,553 |
The jump from 2016 to 2017 is large, and we did not investigate its cause. From 2017 to 2021 the count rose slowly, and growth since 2022 is steady until the 2026 step.
2026 is a different shape
The 2026 total through 18 October is already 69% above all of 2025. A straight line would put the year near 106,000, but publication is not even, so treat that as arithmetic, not a forecast. The data cannot tell us why the count rose, whether through more discovery, more disclosure programmes, more products in scope or a change in how records are created.
A rough ratio to KEV
Entries added to the CISA KEV catalog, as a share of CVE records published in the same year (the two sets are not the same CVEs, so this is only a scale comparison):
| Year | KEV additions | CVEs published | Ratio |
|---|---|---|---|
| 2023 | 187 | 30,949 | 0.6% |
| 2024 | 186 | 40,704 | 0.5% |
| 2025 | 245 | 49,972 | 0.5% |
| 2026 | 264 | 84,553 | 0.3% |
2022 is left out because of the catalog's backlog additions. The point is the scale: well under 1% in recent years. While the count of records grows, the count of vulnerabilities with known exploitation stays in the low hundreds a year.
What to do with the volume
- Do not try to read every CVE. Filter by what you run, using an inventory of products and dependencies.
- Rank what is left by exploitation evidence, exposure and whether the vulnerable code is reachable.
- Report on what you did with the ones that apply to you, not on the total count.
- Be wary of claims that depend on raw totals, in either direction. A bigger number does not show that software got worse.
Most records will never apply to you, and the work is knowing which ones do.
Safeguard's SBOM and dependency scanning lists the components you run, and reachability analysis helps separate vulnerable code your application calls from code it does not. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through the queue and watch how filtering by exposure shrinks the list.
Quick check
Does a higher CVE count mean software is less secure?
Not on its own. The count also reflects more disclosure, more scope and changes in how records are created.
Why does the ratio to KEV matter?
It shows that known exploited flaws are a very small share of all records, which is why filtering by exploitation and exposure matters.
Sources
- NVD CVE API documentation, the API used for yearly counts, queried on 19 October 2026.
- CISA Known Exploited Vulnerabilities catalog, JSON read on 19 October 2026, catalog version 2026.10.16 (1,748 entries).
Last reviewed: 19 October 2026.
