EPSS and KEV Explained: Fixing the CVEs Attackers Actually Use

TL;DR: CVSS measures how severe a vulnerability could be, EPSS estimates the probability that it will be exploited in the wild within the next 30 days, and CISA's KEV catalog lists vulnerabilities already confirmed as exploited. Severity-only triage fails because attackers do not work down the CVSS scale. A practical fix order starts with KEV entries, then high-EPSS findings, and uses CVSS to break ties.

Why does fixing by severity alone fail?

Most vulnerability management programs start the same way: scan, sort by CVSS score, fix the criticals first. It feels rigorous, and it satisfies auditors. It also fails in practice, for two reasons.

The first is volume. The number of published CVEs grows every year, and any environment of reasonable size accumulates more high and critical findings than a team can promptly remediate. When a large share of the queue carries the same red label, the label stops carrying information, and the team falls back to fixing whatever is easiest.

The second reason is more fundamental: CVSS does not measure the thing you actually care about. It estimates how damaging a vulnerability could be if exploited, under standardized assumptions. It says nothing about whether anyone is exploiting it, or ever will. Only a small fraction of published CVEs are ever observed being exploited in the wild, and that fraction does not line up neatly with severity scores. A team fixing strictly by CVSS spends most of its effort on vulnerabilities attackers ignore, while an actively exploited "high" waits in the queue behind untouched "criticals."

What does CVSS actually measure?

The Common Vulnerability Scoring System, maintained by FIRST, produces a base score from 0 to 10 derived from properties of the vulnerability itself: how it can be reached (network, adjacent, or local), how complex the attack is, whether privileges or user interaction are required, and how badly confidentiality, integrity, and availability are affected. The score maps to the familiar labels: low, medium, high, critical.

Notice what is missing: anything about attacker behavior. The base score is essentially static. Once published, it rarely changes, whether the CVE gets weaponized into every exploit kit or is forgotten within a week. CVSS answers "how bad could this be?" and answers it consistently. That makes it a useful measure of impact and a poor priority queue.

What is EPSS and how does it work?

The Exploit Prediction Scoring System, also from FIRST, approaches the problem from the opposite direction. Instead of scoring theoretical impact, EPSS is a data-driven model that estimates the probability that a given CVE will be exploited in the wild within the next 30 days. Scores range from 0 to 1, often read as a percentage, and are recomputed daily as the model ingests fresh signals: observed exploitation activity, availability of public exploit code, vulnerability characteristics, and discussion across public sources.

Two properties make EPSS operationally different from CVSS. It is dynamic: a score can jump overnight when exploit code is published or when scanning-and-exploitation campaigns pick a CVE up. And it is probabilistic: it does not claim that your specific server will be attacked, only how likely exploitation activity is across the ecosystem. That is exactly the forward-looking signal a triage queue needs and CVSS lacks.

What is the CISA KEV catalog?

The Known Exploited Vulnerabilities catalog, maintained by the US Cybersecurity and Infrastructure Security Agency, is not a prediction. It is a curated list of CVEs for which there is reliable evidence of active exploitation in the real world. To be added, a vulnerability must have a CVE identifier, credible evidence of exploitation, and a clear remediation action available, such as a vendor patch.

KEV exists because of a US government mandate: Binding Operational Directive 22-01 requires federal civilian agencies to remediate KEV-listed vulnerabilities by set deadlines. For everyone else, it functions as a free, authoritative ground-truth feed. If one of your exposed services carries a KEV-listed CVE, you are no longer weighing probabilities. Attackers are using that exact flaw against real targets, and yours is one request away from being next.

How do CVSS, EPSS, and KEV compare?

The three are complements, not competitors. KEV is certain but reactive: a CVE lands there only after someone has already been compromised with it. EPSS is predictive but probabilistic. CVSS is stable but blind to the threat landscape. Used together, they cover each other's blind spots.

How do you combine them into a fix order?

A workable triage algorithm looks like this:

1. KEV first, unconditionally. Confirmed exploitation plus a public remediation path is the worst possible combination to leave exposed. Anything internet-facing on the KEV list goes to the front of the queue.
2. High EPSS next. Among findings not on KEV, sort by EPSS. A finding with a high exploitation probability deserves attention this week, regardless of whether its CVSS label says medium.
3. CVSS as the tiebreaker. Within a band of similar EPSS scores, fix the higher-impact vulnerability first. This is where CVSS does its best work.
4. Apply asset context. An internet-facing service outranks an internal one, and a component that has left security support entirely needs a replacement plan rather than a patch, a situation covered in end-of-life software risk.
5. Confirm the finding is real before spending effort on it. A version match does not prove exposure: Linux distributions backport fixes without changing version numbers, which is why patch-status detection belongs in the loop before anything gets scheduled.

This is also how OnScanner presents CVE findings. Fingerprinted products and versions are matched against CVE data, each match carries its EPSS score and KEV flag, patch status separates proven fixes from real exposure, and optional safe, in-band active checks can confirm whether a CVE is actually exploitable on the live target. The methodology page describes the data sources and how the checks stay non-destructive.

What changes when you triage this way?

The queue gets shorter and more honest. Instead of a wall of criticals, you get a small set of "fix now" items backed by evidence of real-world exploitation, a middle tier ranked by likelihood, and a long tail that can be batched into normal patch cycles without anxiety.

It also changes the cadence. Because EPSS shifts daily and KEV grows whenever CISA confirms new exploitation, prioritization is not a one-time sort but a standing process. A CVE you reasonably deferred last month can become urgent overnight. Scheduled scanning that re-evaluates your surface against current EPSS and KEV data closes that gap automatically, which is exactly what continuous monitoring is for.

Frequently asked questions

Should I ignore CVEs with low EPSS scores?

Deprioritize, do not ignore. A low EPSS score means exploitation is unlikely in the near term, not impossible, and scores are recomputed daily as conditions change. Low-EPSS findings belong in routine patch cycles rather than emergency windows. Keep them visible in your tracking, and rely on scheduled re-scanning to flag any that move onto the KEV catalog or spike in probability.

Is a high CVSS score ever the right reason to fix first?

Yes, as a tiebreaker and for context you know but the models do not. Between two findings with similar exploitation likelihood, fix the higher-impact one first. And if a vulnerability sits on a crown-jewel system where exploitation would be catastrophic, its impact can justify early remediation even at modest probability. Severity is the wrong first filter, but it remains a valid second one.

How often do EPSS scores and the KEV catalog change?

EPSS scores are recomputed and published daily by FIRST, so a CVE's probability can shift at any time. The KEV catalog is updated whenever CISA confirms new evidence of exploitation, which in practice means new entries appear regularly throughout the year. Both feeds change often enough that one-time triage goes stale quickly, which is the argument for continuous, scheduled scanning.