Of the 1,748 entries in the CISA KEV catalog, 776 (44%) were added in the same calendar year as their CVE ID, and 1,051 (60%) within a year. But 373 entries (21%) are five or more years old, and 99 are ten or more. Old bugs keep being exploited, so patch queues cannot be about new CVEs alone.
Method
We downloaded the KEV JSON on 19 October 2026 (version 2026.10.16). For each entry we took the year in the CVE ID (for example 2026 in CVE-2026-12345) and the year in dateAdded, and subtracted. This is a rough measure. The year in a CVE ID is the year the ID was reserved, which can differ from the day the flaw became public. It cannot give age in days.
The age spread
| Age at addition | Entries |
|---|---|
| Same year | 776 |
| 1 year | 275 |
| 2 years | 121 |
| 3 years | 106 |
| 4 years | 97 |
| 5 to 9 years | 274 |
| 10 years or more | 99 |
The oldest entries are about 20 years between ID year and the year they were added. These are mostly products that stayed in service long after the flaw was known.
Backlog versus the current rate
The first two years of the catalog distort the picture, because many older exploited bugs were added together when it started. So we split the data.
- Added 2022 and 2023 (742 entries): 212 same year, 288 within a year, 279 aged five or more years.
- Added 2024 to 2026 (695 entries): 444 same year, 547 within a year, 77 aged five or more years, 31 aged ten or more.
In the recent period, 64% of additions are same-year CVEs and 79% are within one year. That is the better guide to what a new KEV addition looks like today. But roughly one in nine recent additions (77 of 695) is still five or more years old, and those are the ones most likely to be missed by a process that only watches the latest releases.
What this means for patching
Two lessons. First, do not drop an old CVE from your list because it is old. A KEV entry is added because someone is exploiting it now, whatever its age. Second, old entries are usually found on older products: legacy servers, appliances past their support dates, and internal tools nobody owns. Finding those is an inventory problem before it is a patching problem.
A practical routine is to match the whole catalog, not only each week's additions, against your asset and dependency inventory once, then watch the additions after that. If a match turns up on a product you no longer maintain, the decision is retire, isolate or replace, because there may be no patch.
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.
See how a standing watch turns a one time match into an alert when the catalog adds something new.
Quick check
Is the CVE ID year the same as the publication year?
Not always. It is the year the ID was reserved, so the measure here is approximate.
Why split the data into periods?
The early catalog added many old bugs at once. Looking at 2024 to 2026 alone gives a fairer picture of current additions.
Sources
- CISA Known Exploited Vulnerabilities catalog, JSON read on 19 October 2026, catalog version 2026.10.16 (1,748 entries).
Last reviewed: 19 October 2026.
