EPSS and the CISA KEV List: Prioritize the Vulnerabilities That Actually Get Exploited
CVSS measures theoretical impact, EPSS predicts real-world exploitation, and the KEV catalog proves attackers are already using a bug. Here is how to turn three scores into a patch queue that reflects actual risk.
π Table of contents
Every year the industry publishes more vulnerabilities than the year before, and 2026 is no exception: well over twenty thousand new CVEs will land, on top of everything already sitting in your backlog. No team patches all of them. The question that actually decides your risk is not "what is vulnerable?" β any decent scanner can tell you that β but "which of these will someone exploit this month?"
Three scoring systems answer that question from different angles, and using only one of them is how teams end up either patching trivia while attackers walk through an old KEV bug, or panic-patching everything and shipping regressions.
What CVSS actually measures (and what it does not)
The Common Vulnerability Scoring System is the industry default. You have seen the format: a base score from 0.0 to 10.0, with 9.0+ rated critical. We have a full CVSS explainer if you want the mechanics; the short version is that the base score combines exploitability and impact into a single worst-case number.
The key word is worst-case. A CVSS base score describes what happens if the vulnerability is exploited under the most favorable conditions for the attacker. It says nothing about whether anyone will bother. The overwhelming majority of critical-rated CVEs are never observed being exploited in the wild β they live in obscure software, require local access, or demand prerequisites that make mass exploitation impractical.
That is not a flaw in CVSS; it is a scope limitation. CVSS is an impact yardstick, not a threat forecast. Treating a 9.8 as an automatic emergency, with no other context, is how security teams burn their most expensive hours on the wrong problems.
EPSS: a probability, not a severity
The Exploit Prediction Scoring System, run by FIRST (the same organization that stewards CVSS), takes the opposite approach. Instead of asking "how bad could this be?", EPSS asks "what is the probability that this vulnerability will be exploited in the wild in the next 30 days?" and returns a number between 0.0 and 1.0.
Under the hood, the model is trained on real-world data: references to the CVE in public exploit repositories, social chatter among security researchers, vendor advisories, and β most importantly β actual exploitation observed in intrusion telemetry shared by participating vendors. The model is refreshed regularly and every CVE's score is regenerated daily, so EPSS reacts when exploit code appears in the wild.
The distribution is brutally skewed, and that is the point. Around 95% of all CVEs score below 0.01 β effectively background noise. A small minority score above 0.5, and those are the ones that show up in ransomware campaigns and initial-access broker toolkits within weeks of publication.
A concrete pattern you will see constantly:
- CVE-A: CVSS 9.8 (critical), EPSS 0.0004. Theoretical monster, practically ignored by attackers.
- CVE-B: CVSS 7.5 (high), EPSS 0.62. Actively exploited right now, in the wild, by many groups.
Sorting your queue by CVSS patches A first. Sorting by EPSS patches B first β which is what actually reduces the chance of an incident this month.
The KEV catalog: proof, not prediction
CISA's Known Exploited Vulnerabilities catalog sits at the far end of the evidence spectrum. A KEV entry means the vulnerability has been observed being exploited in the wild β not modeled, not predicted, observed. Federal agencies are required to remediate KEV entries within timeframes set by Binding Operational Directive 22-01, and the catalog has effectively become a de facto minimum patching standard for the private sector too.
Two properties make KEV uniquely useful. First, it is evidence-based: somebody already ran this exploit against somebody's network. Second, KEV entries skew heavily toward bugs that were exploited long after patches existed β the classic "we knew about it for eight months" breach pattern. Roughly half of the most-exploited vulnerabilities in any given year are not new discoveries at all.
If you do nothing else with this article: search your last scan report against the KEV catalog. Anything on both lists is a fire, not a backlog item.
The three scores side by side
| CVSS | EPSS | KEV | |
|---|---|---|---|
| Question it answers | How bad if exploited? | Will it be exploited soon? | Is it being exploited now? |
| Type | Severity (worst case) | Probability (next 30 days) | Confirmed observation |
| Scale | 0.0 β 10.0 | 0.0 β 1.0 | In catalog or not |
| Producer | FIRST / vendors | FIRST (daily model) | CISA |
| Drives | Impact triage, reporting | Patch order | Emergency response |
None of the three replaces the others. CVSS tells you the blast radius, EPSS tells you the likelihood, KEV tells you the present reality. The teams that get breached least are the ones whose process reads all three.
A prioritization workflow you can run this week
- Pull every finding with a CVE mapping from your last scan. If your scanner does not map findings to CVEs, get one that does β unmapped findings cannot be correlated against threat data at all.
- Sort anything on the KEV catalog to the top. These get patched or mitigated on an emergency clock, regardless of CVSS. An old KEV bug on an internet-facing host is the single most common "how did this happen" in incident reports.
- Apply an EPSS threshold to what is left. Everything above 0.10 on an internet-facing system goes into this week's change window; above 0.50, treat it like a KEV. Below 0.01 on an internal-only system can honestly wait for a scheduled cycle.
- Use CVSS as the depth gauge, not the sort key. When two items compete for the same window, CVSS breaks the tie by telling you which failure hurts more.
- Re-run on a cadence. EPSS moves daily and KEV grows weekly, which means a report from two months ago is quietly lying to you. Prioritization is a process, not a document.
How 2MNY surfaces all three
Every CVE-bearing finding in a 2MNY scan carries three fields next to each other: the CVSS base score, the current EPSS score, and a KEV flag. The findings console lets you filter the entire backlog by "KEV-listed only" or by a minimum EPSS, so the workflow above is three clicks instead of a spreadsheet exercise. The scanner re-correlates against current threat data on every scan, so a vulnerability that was quiet last month and got weaponized this week surfaces at the top of the new report β not buried at the severity position it had when you first found it.
You can run a free scan and see your own EPSS/KEV exposure at 2mny.com β findings are evidence-verified, meaning the scanner proves what it can before it scores it, so the numbers you prioritize against are numbers you can trust.
The uncomfortable truth of vulnerability management is that you will never fix everything. EPSS and KEV exist so that the things you leave unfixed are, with high confidence, the things attackers will leave unexploited.
Security engineer building 2MNY β 292 free website-security checks β and the open-source Website Vulnerability Scanner. I find exposed secrets, misconfigurations and real vulnerabilities, then explain how to fix them in plain language.
1 How often is the EPSS model updated?
FIRST releases a new EPSS model version roughly every six months and regenerates scores for all CVEs daily. That means a vulnerability's EPSS can move from negligible to high within days of exploit code appearing in the wild, which is exactly why point-in-time reports go stale and continuous monitoring matters.
2 Is EPSS better than CVSS?
They answer different questions. CVSS describes the worst-case technical impact of a bug if it is exploited; EPSS estimates the probability that it actually will be exploited soon. For prioritization, EPSS is the better sorting key, while CVSS still matters for understanding blast radius once you decide to fix something. The best workflows use both.
3 What is a good EPSS score?
There is no universal cutoff, but in practice EPSS above 0.10 (a 10% chance of exploitation within 30 days) is where security teams start treating a vulnerability as urgent, and above 0.50 it is near-certain to be attempted. Because roughly 95% of published CVEs score below 0.01, even a modest threshold cuts a giant backlog down to the handful that matter.
4 What is the CISA KEV list?
The Known Exploited Vulnerabilities catalog is maintained by CISA and lists vulnerabilities with confirmed, active exploitation in the wild. Under Binding Operational Directive 22-01, US federal agencies must remediate KEV entries within set deadlines, and most enterprises follow the same rule. A KEV listing is the strongest public signal that attackers are using a bug right now.
