Which vulnerability to patch first: how EPSS, CISA KEV and SSVC work, with a triage you can run today

In short

A CVSS score tells you how bad a vulnerability could be in the worst case; it does not tell you whether anyone is attacking it, or whether it matters on your machines. To decide what to patch first, combine three more signals: CISA's KEV catalogue (is it confirmed exploited in the wild?), EPSS (what is the estimated chance it will be exploited in the next 30 days?) and SSVC (a decision tree that ends in an action and a deadline, not a number). Start with KEV, then exposure, then EPSS, and use CVSS to describe the damage, not to rank the queue.

Why CVSS alone is a poor queue

Every week brings hundreds of new CVE identifiers, and the usual first question is "what is the score?". We explained how to read a CVSS vector string and why a 10.0 is not the same as risk in an earlier guide. The short version: the base score describes a flaw's characteristics (reachable over the network, needs no password, gives full control) in a standard way. It says nothing about whether exploit code exists, whether attackers care, or whether the vulnerable component is exposed in your environment.

The maintainers of EPSS put it bluntly in their FAQ, quoting the CVSS v4.0 FAQ: "CVSS-B Base scores are not risk." So a scanner report sorted by CVSS puts the same weight on a 9.8 in a library nobody can reach and a 7.5 in the web server facing the internet that attackers are already using.

A live example from this week shows the gap. CVE-2026-83844, a code execution flaw in Windows 11 Paint, carries a CVSS 3.1 base score of 8.1 (High). The CISA coordinator's entry in the CVE record, added on 13 October, records exploitation "none" and automatable "no". A tracker cited by WindowsForum puts its EPSS probability at 0.73% on 4 November, and a separate check found it absent from KEV in a copy dated 30 October. Same bug, four different readings, and they point to "important, but not an emergency", unless you cannot patch at all, in which case the fact that the patch is hard to get (see that article) changes the picture.

The three signals

1. KEV: a record of what has happened

The Known Exploited Vulnerabilities catalogue is maintained by the US Cybersecurity and Infrastructure Security Agency (CISA). Its page describes it as "the authoritative source of vulnerabilities that have been exploited in the wild" and advises organisations to "use the KEV catalog as an input to their vulnerability management prioritization framework." Each entry shows the date added and a due date for US federal agencies. In the sample entries we saw on the page, those due dates were 3 days after the addition for some (added 26 October, due 29 October) and 14 days for others (added 28 October, due 11 November). The page itself does not explain how a due date is chosen, and it cites BOD 26-04, a CISA directive for agencies.

What KEV is good at: it is a short list of things that really are being used against someone. According to the EPSS FAQ, KEV lists roughly 0.5% of published CVEs. If a vulnerability in software you run is on it, that outranks everything else in this guide.

What KEV is not: a forecast. A vulnerability that is not listed may simply not have been noticed yet. It is also a record of history: entries appear after exploitation is confirmed. We have covered several, for example CVE-2026-119977 in WordPress core and CVE-2026-46300, the Linux root flaw "Fragnesia".

2. EPSS: a forecast

The Exploit Prediction Scoring System, run by a special interest group at FIRST with data and infrastructure supplied by Empirical Security, "estimates the probability a vulnerability will be exploited in the wild within the next 30 days". It gives every public CVE a score between 0 and 1, recalculated daily, and publishes it free through a CSV download and an API, with no registration.

Three facts from the FAQ help you read it correctly:

• It is a probability, calibrated. Among many vulnerabilities scored around 0.05, exploitation activity is expected to be observed for about 5 of every 100 over the next 30 days.
• Most scores are small, because most vulnerabilities are never attacked. In any 30-day window the data partners observe exploitation activity for roughly 2.5 to 3% of published CVEs, so a 5% score already ranks in the top 10% of all vulnerabilities. The FAQ says that a probability of 0.10 currently sits around the 95th percentile.
• It moves. The score changes overnight when new signals arrive: public exploit code, detection signatures, a spike in chatter or a detailed analysis. A rising score is a warning even if the number is still small.

What EPSS is not, in the FAQ's own words: "not a complete risk score". It does not measure how much damage exploitation would cause or whether you are affected, and it knows nothing about your compensating controls. The FAQ also warns against a popular shortcut: multiplying EPSS by CVSS "does not compute probability × severity and is never a good idea", because one is a calibrated probability and the other an uncalibrated expert ranking. Finally, a low EPSS score on a KEV-listed vulnerability "is not a contradiction": KEV is history, EPSS is a forecast, and the FAQ says KEV should take precedence when present.

3. SSVC: a decision, not a number

SSVC, the Stakeholder-Specific Vulnerability Categorization, comes from the CERT Coordination Center. Its documentation calls it "a methodology for prioritizing vulnerabilities based on the needs of the stakeholders involved". Instead of a score, you answer a few questions about the vulnerability and your situation and walk a decision tree that ends in an action.

The documentation's example for people who run software (the "deployer" model) ends in one of four priorities:

• Defer: do not act at present.
• Scheduled: act during regularly scheduled maintenance time.
• Out-of-cycle: act more quickly than usual, at the next available opportunity, "working overtime if necessary".
• Immediate: act immediately and focus all resources on the fix, pausing regular operations if necessary.

For US federal agencies, the SSVC project documents a "CISA Response Timeline" tree supporting BOD 26-04. It uses four yes-or-no questions: is it in KEV, is the asset publicly exposed, is exploitation automatable, and what is the technical impact. The outcomes are time limits: fix on the next system upgrade, within 60 days, within 14 days, within 3 days, or within 3 days plus a forensic investigation of the asset to check whether it is already compromised. The last outcome adds a forensic triage of the asset, to assess whether it is already compromised.

The "automatable" and "technical impact" answers are the same fields that CISA's coordinator entry carried on the Paint record above, so you can sometimes read them straight off a CVE record.

A practical triage you can run today

You do not need a tool to start. For each new vulnerability in software you actually run:

1. Do you run the affected product and version? If you cannot answer, that is your first problem: keep an inventory. If not affected, stop.
2. Is it in KEV? Yes: treat it as urgent. For an internet-facing system, patch within days, and where the guidance calls for it, check the system for signs it was already compromised (see our write-ups of CVE-2026-97229 in GitLab and how the same flaw hit a server beyond GitLab itself).
3. Is the asset reachable by untrusted users or the internet? Exposed assets move up; internal-only assets, behind other controls, can usually wait for the maintenance window.
4. What is EPSS, and is it rising? Use it to order the rest of the queue, and re-check it: a jump from 1% to 20% in a week means exploit code or attacks have probably appeared.
5. What does the damage look like? Here CVSS and technical impact are useful: remote code execution or full takeover outranks a limited information leak at the same exploitation likelihood.
6. No patch yet? Use mitigations: shut the service, restrict access, remove the component. The SSVC documentation says that when no remediation exists, "the action space is more diverse, but it should involve mitigating the vulnerability".

Write the answer down in one of the four SSVC words (Defer, Scheduled, Out-of-cycle, Immediate) next to the ticket. It forces a decision and gives you something to audit later.

Common mistakes

• Sorting by CVSS only. It buries the 7.5 that is under attack beneath dozens of unexploited 9.8s.
• Treating "not in KEV" as "safe". It means "no confirmed exploitation recorded", not "no exploitation".
• Treating a low EPSS number as a pass. Low is the normal state; look at the trend and combine it with exposure.
• Multiplying scores together. The EPSS FAQ explicitly advises against it.
• Assuming the OS update covers everything. As the Paint case shows, apps delivered separately from the monthly update need their own version check.
• Ignoring dates. All of these signals are snapshots; the numbers above are from early November 2026 and will change.

Sources

• FIRST: EPSS Frequently Asked Questions
• CISA: Known Exploited Vulnerabilities Catalog
• CERT/CC: SSVC, Stakeholder-Specific Vulnerability Categorization
• SSVC: Deployer patch deployment model
• SSVC: How to use the CISA Response Timeline decision tree
• FIRST: CVSS v3.1 specification
• CVE record for CVE-2026-83844 and WindowsForum summary of EPSS and KEV status