Only 1.48% of CVEs were confirmed exploited. What should vulnerability teams do?

Security teams do not have a vulnerability detection problem. They have a decision problem.

Every new scanner, feed and asset source adds findings to an already crowded queue. The familiar response is to sort by severity, start with critical CVEs and work downward. It feels defensible because the numbers look objective. Yet a severity score describes the potential technical impact of a vulnerability. It does not tell you whether attackers are exploiting it, whether they can reach the affected asset or whether your organization has a workable fix.

New research from Root Evidence puts numbers behind that distinction. Its Vulnpocalypse report analyzed 253,912 CVEs published from January 1, 2018 through July 15, 2026. The researchers matched those vulnerabilities against confirmed exploitation records from the CISA Known Exploited Vulnerabilities catalog and VulnCheck KEV.

The result deserves attention: 3,769 vulnerabilities had confirmed exploitation in the dataset. That is 1.48% of all CVEs examined.

This does not mean the other 98.52% are harmless. It means vulnerability volume and observed attacker behavior are different datasets, and remediation programs need to treat them that way.

‍

What did the Vulnpocalypse report find?

The report’s clearest finding is that confirmed exploitation remains concentrated in a small share of published vulnerabilities. Even as annual CVE volume grew, the proportion with confirmed exploitation stayed below 2.2% in every complete year from 2018 through 2025.

The second finding is equally important for remediation. Of the 3,769 exploited vulnerabilities, 3,058, or 81.1%, were n-days. A patch was available before exploitation was first observed. The remaining 711 were classified as zero-days because exploitation was observed before a patch became available.

For 2026 through mid-July, the median interval between patch release and confirmed exploitation was 116 days. However, roughly one-third of exploited vulnerabilities were hit within 30 days. A median should therefore describe the dataset, not become a default patching deadline.

The evidence supports three conclusions:

1. Raw CVE counts are a poor proxy for the work that reduces the most risk.
2. Most confirmed exploitation in the dataset involved vulnerabilities that defenders could already patch.
3. Exploitation timing has a fast tail that makes broad, calendar-based service levels unsafe.

‍

What the research does not prove

The 1.48% figure is a confirmed-exploitation rate within the sources and period studied. It is not a complete measurement of every attack.

Public exploitation catalogs are valuable, but they cannot include activity that was never detected, disclosed or attributed to a specific CVE. They may also overrepresent products and incidents that receive strong telemetry and researcher attention. Root Evidence is a commercial vendor, which makes transparent methods and independent reproduction especially important.

The report also found no broad surge in observed exploitation that matched the growth in published CVEs. That finding challenges claims that AI has already caused a universal collapse in exploitation timelines. It does not prove AI will have no effect, or that it has no effect in particular campaigns.

Good vulnerability management uses this evidence without stretching it beyond what it measures.

Why risk-based prioritization must go beyond CVSS

CVSS remains useful for describing technical severity. EPSS estimates the probability of exploitation over a defined period. KEV indicates that exploitation has been observed and validated for listed vulnerabilities. None of them, alone, describes the risk to a particular organization.

A defensible priority decision should combine several questions:

• Is exploitation confirmed, predicted or only theoretically possible?
• Is a public exploit or weaponized capability available?
• Can an attacker reach the affected service in this environment?
• Does the vulnerable condition exist on the asset, rather than merely matching a version string?
• What business process depends on the asset?
• Is a patch available, and can it be deployed safely?
• If patching is delayed, can another control reduce the exposure?

This is the difference between a vulnerability score and an exposure decision. The first describes a weakness. The second determines what the team should do next.

‍

What this means for remediation strategy

The most useful reading of the 81.1% n-day figure is operational. In the researchers’ dataset, attackers usually exploited vulnerabilities after a patch already existed. The central failure was often not an absence of security information. It was the inability to translate available information into timely action.

That points toward a remediation-first workflow:

1. Confirm the affected asset and vulnerable condition.
2. Enrich the finding with exploitation evidence and environmental context.
3. Select a supported fix path, such as a patch, configuration change, compensating control or temporary protection.
4. Test and deploy the action according to the asset’s operational risk.
5. Validate that the vulnerable condition or reachable exploit path is gone.

The fifth step matters. A closed ticket proves that a workflow ended. It does not prove that exposure fell.

Vicarius vScore reflects this broader model by combining CVSS, EPSS and KEV with exploitability, asset criticality and business context. The product connection should remain precise: the Root Evidence report supports evidence-based prioritization as a category direction. It does not independently validate any vendor’s scoring model.

‍

How security leaders should communicate the finding

“Only 1.48% are exploited” is memorable, but it can easily become the wrong message. It should not be used to dismiss vulnerability management or justify waiting for exploitation to appear in a public catalog.

The better message is that teams need to spend scarce remediation capacity where evidence indicates it will reduce the most exposure. Confirmed exploitation is powerful evidence, but it belongs beside reachability, asset value, control coverage and the availability of a safe remediation.

Security leaders should also resist the opposite mistake: treating every critical vulnerability as an emergency. When everything is urgent, operational teams learn to distrust the queue. A smaller, evidence-backed set of actions is more likely to be completed and verified.

‍

Frequently asked questions

Does the research mean only 1.48% of vulnerabilities are dangerous?

No. The report found confirmed exploitation for 1.48% of the CVEs in its dataset. Unobserved or undisclosed exploitation will not appear in public catalogs, and a vulnerability can still create material risk before exploitation is confirmed.

Should teams patch only vulnerabilities listed in KEV?

No. KEV is a strong prioritization signal, not a complete remediation policy. Teams should also consider predicted exploitation, public exploit availability, internet exposure, asset criticality and controls already in place.

Is 116 days a safe remediation deadline?

No. It was the median patch-to-exploitation interval reported for 2026 through mid-July. Roughly one-third of exploited vulnerabilities were hit within 30 days, so exposure-specific decisions remain necessary.

The practical takeaway

The research does not make vulnerability remediation less urgent. It makes indiscriminate remediation harder to defend.

The stronger program is not the one that counts the most findings or closes the most tickets. It is the one that can show why each action was prioritized, how the exposure was addressed and whether the risk actually decreased.

That is the real promise of risk-based vulnerability prioritization: fewer decisions driven by fear, more decisions grounded in evidence and a shorter path from detection to verified remediation.

‍