Often yes, according to FIRST. In its EPSS documentation, vulnerabilities older than two years are exploited at roughly five times the rate of those less than a month old, and age is the single largest vulnerability characteristic in the model. It is a population pattern, not a rule for any one CVE.
What FIRST actually says
The EPSS How It Works page states that age contributes more to individual predictions than any other single vulnerability characteristic. It calls this often a surprise to practitioners. It then says that vulnerabilities older than two years are exploited at roughly five times the rate of vulnerabilities less than a month old, and that the underlying mechanisms are only speculative.
FIRST offers two guesses. Perhaps it takes time for exploit tooling to mature and attacker workflows to adopt a CVE. Perhaps it takes time for the ecosystem to understand the risk. It also warns that the relationship is not perfectly monotonic, and that behavior around new CVEs is more complex than a simple age rule.
Why this surprises people
Teams often chase the newest CVE in the news and let old ones sit. The news cycle is loud for a new flaw. But an older flaw with mature tooling, a long reference trail and many unpatched systems can be easier for an attacker to use in bulk. A scan that finds an old, forgotten library is not good news just because the CVE is from years ago.
What it does not tell you
- It does not say a given old CVE is dangerous. Most old CVEs are never exploited. FIRST says the base rate in any 30 day window is roughly 2 to 3 percent of published CVEs.
- It does not say new CVEs are safe. A newly disclosed flaw in an exposed component can be attacked quickly, and EPSS has only sparse data on day one.
- It does not apply to your estate. Whether you run the affected component, and whether it is reachable, still decides your exposure.
- It is a statement about rates across a population, so it cannot replace a check on your own system.
Turning it into practice
| Situation | Suggested handling |
|---|---|
| Old CVE, high EPSS, component present and reachable | Treat as high priority, even if it is years old |
| Old CVE, low EPSS, not reachable | Keep on the normal schedule |
| New CVE, sparse data, exposed component | Re-check daily until signals settle |
| Old CVE on the CISA KEV list | Follow KEV, which records real exploitation |
A practical habit: sort your backlog by current exploit signals, not by CVE year. A filter such as "published this month" can hide the old item that matters.
Sweep your old findings
Run a pass over findings older than two years. For each one, check three things: is it on KEV, what is its current EPSS probability, and is the vulnerable code used. Many will fall away. The remaining few are the ones that earn attention, and they have often been sitting unnoticed.
Safeguard's reachability analysis shows whether vulnerable code in a dependency is actually used, and SBOM and dependency scanning find the old packages in the first place. 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 many findings drop out once unreachable ones are set aside, then picture that on your oldest backlog items.
Quick check
Is a CVE from several years ago low priority?
Not automatically. FIRST reports older CVEs are exploited at a higher rate than very new ones in aggregate. Check KEV, current EPSS and whether the code is reachable.
Why is age such a strong signal?
FIRST says the mechanisms are speculative. It suggests tooling and attacker workflows may take time to mature, and that the ecosystem may need time to understand the risk.
Sources
Last reviewed: 19 October 2026.
