CVSS vs EPSS vs KEV: Which Signal Should Decide What You Patch First?

Check the CISA Known Exploited Vulnerabilities (KEV) catalog first, then EPSS, then CVSS, and apply your own knowledge of exposure at every step. KEV tells you a flaw has been exploited. EPSS estimates how likely exploitation is when you have no such evidence. CVSS tells you how bad exploitation would be. Using any one of them alone produces a predictable failure, and seven flaws from the past two weeks show each failure clearly.

This article explains what each signal measures, tests them against those seven flaws, and gives an order of operations you can implement.

What each one measures

CVSS: severity, not risk

The CVSS v4.0 specification describes the base score as reflecting a vulnerability’s severity according to intrinsic characteristics that stay constant over time. It covers things like whether the flaw is reachable over a network, whether the attacker needs an account, and what happens to confidentiality, integrity and availability.

The qualitative labels map to score ranges: Low is 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9 and Critical 9.0 to 10.0.

CVSS v4.0 has three other metric groups that most published scores leave empty:

• Threat metrics, mainly Exploit Maturity, which can be set to Attacked, Proof-of-Concept or Unreported.
• Environmental metrics, which adjust for your own controls and how much the affected system matters to you.
• Supplemental metrics, which add context without changing the score.

The specification names scores by which groups were used: CVSS-B is base only, CVSS-BT adds Threat, CVSS-BE adds Environmental and CVSS-BTE uses all three. It expects vendors and analysts to supply base metrics and the consuming organization to supply Threat and Environmental ones. In practice, the number in an advisory or scanner report is almost always CVSS-B, which is the general-case severity and nothing more.

Two scoring versions are in circulation. Among the flaws discussed below, Cisco and Fortinet published CVSS 3.1 scores and Citrix published CVSS 4.0 scores. The two versions are calculated differently, so treat a 9.8 on one and a 9.5 on the other as “both Critical”, not as a ranking.

EPSS: likelihood, with a time window

FIRST’s FAQ defines EPSS as “a data-driven model that estimates the probability a vulnerability will be exploited in the wild within the next 30 days.” Three details matter when you read a score:

• It is a probability. A score of 0.02 means an estimated 2% chance of observed exploitation activity in the next 30 days.
• The percentile is a ranking, not a probability. A percentile of 0.82 means the score is higher than 82% of all scored CVEs. Because most CVEs have very low scores, a high percentile can sit on top of a small probability. When we queried the API on October 7, 2026, it reported about 383,000 scored CVEs.
• “Exploitation activity” means attempts. FIRST’s model description defines it as evidence that exploitation was attempted, not that it succeeded, and says the data comes from sources such as honeypots, intrusion detection sensors and host-based detection.

Scores are republished every day, typically just after 13:30 UTC according to the FAQ.

FIRST is direct about the limits. The FAQ says “EPSS is not a complete risk score”, that it does not measure how much damage exploitation would cause or whether a flaw affects your environment, and that “multiplying EPSS by a CVSS score does not compute probability × severity and is never a good idea.”

KEV: evidence, not prediction

CISA adds a vulnerability to the catalog when three conditions are met: it has a CVE ID, “there is reliable evidence that the vulnerability has been actively exploited in the wild”, and “there is a clear remediation action for the vulnerability, such as a vendor-provided update.”

CISA’s definition of exploitation is specific. Scanning, security research on an exploit and the existence of a proof of concept do not count. Attempted exploitation, including against a honeypot, does.

As of catalog version 2026.10.04, the catalog held 1,734 entries, of which 250 were added in 2026. It flags 361 entries, about 21%, as known to be used in ransomware campaigns.

What a listing does not tell you is how widespread exploitation is, or whether you are a likely target. And the criteria imply two gaps, which is our reading rather than CISA’s wording: a flaw can be exploited before CISA has reliable evidence of it, and a flaw with no clear remediation does not meet the third criterion. Absence from KEV means “no listing”, not “not exploited”.

A fourth signal you already have: CISA’s SSVC values

SSVC (Stakeholder-Specific Vulnerability Categorization) is a decision-tree method that CISA says was created in 2019. CISA’s version uses five decision points, including exploitation status, technical impact and whether exploitation is automatable, and ends in one of four outcomes: Track, Track*, Attend or Act.

The useful part for day-to-day triage is that CISA publishes three of those values inside many public CVE records: Exploitation (none, proof of concept or active), Automatable (yes or no) and Technical Impact (partial or total). Automatable asks whether an attacker can reliably automate creating exploitation events for the vulnerability, in the wording of the SSVC project’s documentation. A flaw marked active, automatable and total impact is the kind that gets sprayed across the internet.

Seven exploited flaws, three signals

We covered seven flaws that CISA added to KEV between September 27 and October 4, 2026. The table puts their published CVSS base scores next to their EPSS scores for October 6, 2026 and CISA’s Automatable value.

EPSS values are rounded from the API’s figures, which run from 0.00592 to 0.02201. The Zammad records also carry a second score of 9.4 for the two flaws chained together.

What each signal would have done on its own:

• EPSS alone would have missed all seven. Every score is at or below 2.2%. A team that acts on EPSS of 10% or higher, a commonly used cut-off, would have flagged none of them. Even a team working by percentile and taking the top 10% of CVEs would have flagged none, since the highest sits at the 82nd percentile.
• CVSS “Critical only” would have missed three. Four of the seven score 9.0 or higher. The two Zammad flaws and the NetScaler denial-of-service flaw score 8.5 to 8.7, which is High. A rule of 7.0 and above catches all seven, but that rule also puts every High and Critical flaw in your inventory into the same urgent queue, which is the backlog problem in the first place.
• KEV caught all seven, by construction. We picked these because they were listed. That is the point of the comparison, not a flaw in it: for a flaw with exploitation evidence, the evidence is the signal.

This is not a criticism of EPSS, and seven flaws are not a statistical sample. EPSS is doing what FIRST says it does. Its FAQ states that the model generates scores “without knowing if the vulnerability was recently exploited” and that “if direct evidence of active exploitation exists, that evidence should supersede EPSS.” These were newly disclosed flaws: CISA added all seven to KEV within two days of their CVE records being published. That is the situation where a model built on broad observation has the least to work with, which is our interpretation, not a statement from FIRST.

The mistake would be on the reader’s side: seeing 0.6% next to a CVE and lowering its priority without checking KEV.

An order of operations

This sequence is our recommendation. It uses each signal for the question it can answer.

1. Is it in KEV, or does the vendor say it is being exploited? If yes and the affected system is reachable from untrusted networks, act now, and plan a compromise check as well as a patch. If the system is internal only, schedule it within days. Vendor statements count: Fortinet’s advisory for CVE-2026-104286 said the flaw was being exploited on the day it was published.
2. If not, what does EPSS say? A score above your chosen threshold moves the item up. Pick the threshold from your capacity: lower it until the resulting queue is the size your team can clear.
3. If EPSS is low, is it Critical and exposed? A CVSS base score of 9.0 or higher on an internet-facing system still deserves the next patch cycle, because a low EPSS score on a fresh CVE can change quickly.
4. Everything else follows the routine schedule.

At every step, the exposure question is yours to answer. None of the three sources knows whether your FortiMail web interface faces the internet.

Here is that logic as a small Python function. It is an illustration of the ordering, not a finished tool. We ran it against the KEV data file and the seven flaws above; the thresholds are examples.

import json

EPSS_WATCH = 0.10  # probability, not percentile; tune to your own capacity


def load_kev(path: str) -> set[str]:
    with open(path) as f:
        return {v["cveID"] for v in json.load(f)["vulnerabilities"]}


def triage(cve: str, cvss: float, epss: float, internet_facing: bool, kev: set[str]) -> str:
    if cve in kev:
        return "1 - act now" if internet_facing else "2 - this week"
    if epss >= EPSS_WATCH:
        return "2 - this week" if internet_facing else "3 - next cycle"
    if cvss >= 9.0 and internet_facing:
        return "3 - next cycle"
    return "4 - routine"

load_kev reads the JSON file CISA publishes at github.com/cisagov/kev-data. With the KEV check in place, all seven flaws returned “1 - act now” for an internet-facing system. With an empty KEV set, simulating a team that skips that check, four returned “3 - next cycle” and three returned “4 - routine”. Same flaws, same scores, one missing lookup.

Daily EPSS scores are available from FIRST’s API at https://api.first.org/data/v1/epss?cve=CVE-2026-104286, which accepts a comma-separated list of CVE IDs.

Common mistakes

• Sorting the backlog by CVSS and working from the top. This treats a Critical flaw on an isolated test server as more urgent than a High flaw being exploited on your gateway.
• Reading a low EPSS score as “safe”. It is a 30-day estimate from a model. Check KEV and the vendor advisory before lowering priority.
• Confusing EPSS percentile with probability. “82nd percentile” sounds urgent. The probability behind it in the table above is 2.2%.
• Treating KEV as complete. It lists what CISA has evidence for and can point to a fix for.
• Multiplying the scores together. FIRST says not to. The result has no defined meaning.
• Recording “patched” instead of the fixed version. Citrix issued two bulletins for NetScaler within a week, and the builds that fixed the first were still affected by the second, as we covered in the NetScaler CVE-2026-88779 article.
• Trusting one data source for affected versions. In the FortiMail case, the CVE record and the vendor advisory listed different version ranges.

For the organizational side of this, including why backlogs grow when everything is ranked by count, see the vulnerability backlog that never shrinks. For what to do once something lands in the top tier, see how to respond to a zero-day.

Sources and verification

Checked on October 7, 2026. EPSS scores change daily and the KEV catalog grows, so the figures below describe those dates only. The seven flaws were chosen because we had already reported on them; they are examples, not a representative sample.

Vulnerability ManagementProcess