EPSS And CVSS Triage Prioritizer
Severity is not priority. This page takes a CVSS base score, an EPSS exploitation probability, CISA KEV membership, asset exposure and data sensitivity, and returns a P1 to P4 remediation band from a fixed decision table. The exact rule that fired is printed under every result, so you can argue with the tool instead of trusting it. Everything runs in your browser with no lookups and no requests.
What this tool does not do
- It does not look up any CVE. It performs no network requests of any kind, so it cannot fetch an EPSS score, a KEV entry or a CVSS vector. Every number below comes from what you typed.
- It does not invent EPSS values. If you do not have the real EPSS score for the CVE, get it from the FIRST EPSS data feed before using this page. A guessed EPSS produces a confidently wrong band.
- The decision table is a defensible default, not a standard. CVSS, EPSS and KEV are published artefacts; the mapping from those three to P1 through P4, and the remediation windows in days, are this page's own policy. Replace them with your organisation's SLA if you have one.
- The expected risk figure is an ordering heuristic, not a probability, not a loss estimate and not a calibrated score.
Why CVSS alone misprioritises
A CVSS base score answers one question: if this vulnerability were exploited, how bad would it be? It is a measure of intrinsic severity under worst reasonable assumptions. It deliberately says nothing about whether anyone is actually exploiting the bug, whether exploit code exists, or whether the affected host is reachable from the internet. Those are separate questions, and they are the ones that decide what you should patch on a Monday morning.
The practical consequence is a queue problem. Organisations that treat "CVSS 7.0 and above" as the remediation trigger commit to patching roughly half of everything published, which for a large estate is tens of thousands of items per year. The queue cannot be cleared, so it is worked in an arbitrary order, and the small number of vulnerabilities that are genuinely being exploited sit in the same undifferentiated pile as everything else.
The corrective is to add a likelihood signal. EPSS, the Exploit Prediction Scoring System maintained by FIRST, estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. It is a probability between 0 and 1 and it is updated daily. Its distribution is severely skewed: the large majority of published vulnerabilities, including a large majority of those scoring CVSS 9.0 and above, carry an EPSS score below 0.1, which is a less than 10 percent chance of observed exploitation activity in the next 30 days. Severity and likelihood are only weakly related, which is exactly why sorting by severity over-prioritises.
Expected risk as an ordering aid
The simplest way to see the mismatch is to multiply the two numbers:
A CVSS 9.8 with an EPSS of 0.0042 scores 0.041. A CVSS 5.3 with an EPSS of 0.37 scores 1.961, roughly 48 times higher, despite being four and a half points less severe. That ratio is the whole argument in one line. The figure is not a probability of loss and it is not calibrated against anything; it is a monotonic ordering aid that stops a merely severe item from outranking an actively exploited one.
Why KEV overrides the arithmetic
The CISA Known Exploited Vulnerabilities catalogue is not a prediction. It is a list of vulnerabilities for which there is reliable evidence of exploitation in the wild, added only when that evidence exists and a remediation action is available. United States federal civilian agencies operate under Binding Operational Directive 22-01, which sets mandatory remediation deadlines for catalogue entries. For everyone else it functions as the highest-confidence signal available: the question "will this be exploited" has already been answered.
That is why KEV membership is handled as an override in the table below rather than as another input to a score. A predicted probability, however good the model, should never outweigh an observation. If a KEV item is reachable from the internet it is P1, whatever its CVSS says.
The decision table
Rules are evaluated top to bottom and the first matching rule wins. The result panel prints the identifier of the rule that fired along with the full arithmetic.
Step 1: KEV override rules
| Rule | Condition | Result |
|---|---|---|
| R1 | In KEV and internet facing | P1, terminal. CVSS, EPSS and data sensitivity are ignored. |
| R2 | In KEV and internal only | Base band P2, then the sensitivity shift in step 3 |
| R3 | In KEV and isolated | Base band P3, then the sensitivity shift in step 3 |
| R4 | Any KEV item after shifts | Floored at P3. A KEV item is never assigned P4. |
Step 2: severity and likelihood matrix, for items not in KEV
CVSS tiers use the standard qualitative ranges. EPSS tiers are this page's own thresholds at 0.10 and 0.01.
| CVSS tier | EPSS high, 0.10 and above | EPSS moderate, 0.01 to 0.10 | EPSS low, below 0.01 |
|---|---|---|---|
| Critical, 9.0 to 10.0 | P1 | P2 | P3 |
| High, 7.0 to 8.9 | P1 | P2 | P3 |
| Medium, 4.0 to 6.9 | P2 | P3 | P4 |
| Low, 0.1 to 3.9 | P3 | P4 | P4 |
| None, 0.0 | P4 | P4 | P4 |
Note the top two rows are identical. Once likelihood is in the model, the difference between a 9.8 and a 7.5 stops carrying decision weight, which is the intended behaviour.
Step 3: context shifts
Bands are numbered 1 to 4. A negative shift is more urgent, a positive shift is less urgent.
Rule M1 caps the combined escalation at a single band. Exposure and data sensitivity are context, not evidence of exploitation, and two pieces of context should not be able to promote a low-likelihood item two bands up the queue. De-escalation is not capped in the same way, because an isolated host holding no sensitive data genuinely is a lower priority. For KEV items only the sensitivity shift is applied, since exposure has already been consumed by rules R1 to R3.
Step 4: remediation windows
| Band | Meaning | Suggested window |
|---|---|---|
| P1 | Fix now | 7 days, out of cycle change if needed |
| P2 | Fix this sprint | 30 days |
| P3 | Scheduled | 90 days, next maintenance window |
| P4 | Accept risk | No scheduled work, review in 180 days |
These windows are defaults chosen to be defensible, not deadlines drawn from any regulation. If you are bound by a specific standard or contract, its numbers win over these.
Reading the result honestly
Two failure modes are worth naming. First, EPSS moves. A vulnerability at 0.004 today can be at 0.6 next week when exploit code is published, so a P3 decision made once is not a P3 decision forever; re-run anything you deferred when the EPSS feed refreshes. Second, EPSS is a model of observed exploitation activity across the internet, not a statement about your estate. A vulnerability nobody is mass exploiting can still be the one a targeted attacker uses against you, which is why the exposure and sensitivity inputs exist and why P4 means accepted rather than safe.