Three scores, three answers —
and what to do when they disagree.

Three numbers follow a vulnerability around, and most teams treat them as three attempts to say the same thing. They are not. CVSS says how bad it would be. CISA KEV says whether it is actually being exploited. EPSS says how likely exploitation is in the next 30 days. Three different questions, three answers that routinely point in opposite directions.

We now publish all three side by side on our Exploited & Unpatchable feed — twelve vulnerabilities that are confirmed exploited, present in end-of-life software, and will never receive a patch for the affected versions. That small, hand-verified set turns out to be an unusually clean place to watch the three signals argue with each other.

This article is about reading them together. If you want the definitions first, start with What is a CVE?, which covers what each score is and who assigns it. Here we assume you know that and get to the harder part: what to do when they disagree.

The three questions, precisely stated

The scores are not interchangeable, and the confusion is usually about tense. CVSS is conditional and timeless: if this were exploited, how bad. KEV is a statement of fact: this has been exploited. EPSS is a forecast: this is how likely exploitation is next.

Twelve vulnerabilities, scored three ways

Every entry below is on CISA KEV, so the exploitation question is already answered yes for all twelve. What varies is severity and near-term probability. EPSS values are from the FIRST.org model run of 2026-08-13, retrieved 2026-08-14; CVSS is as recorded on our feed, with its source noted there.

Two things stand out. Nine of the twelve sit above 83% — the top tier of everything EPSS scores — which is a reasonable check on the feed’s selection: hand-picking “actively exploited and unpatchable” lands on genuinely high-probability vulnerabilities.

The other three are the interesting ones.

Case 1: confirmed exploited, lowest probability in the set

FortiOS, CVE-2025-68686. CVSS 5.9 — medium. EPSS 1.26% — the lowest on our feed by a wide margin. And it is on CISA KEV, added 2026-07-27, with a federal remediation deadline of 2026-08-10 that has now passed.

Every automated triage rule that keys on severity or probability drops this one. A “CVSS 7.0 and above” policy never sees it. An “EPSS above 10%” policy never sees it. Yet it is confirmed exploited.

The reason the numbers read low is worth understanding, because it is not a flaw in either score. This is a persistence weakness: symlink-based access that survives patching, abused after an attacker has already exploited a separate vulnerability to reach the filesystem. CVSS scores it as requiring high attack complexity, with no integrity or availability impact — defensible in isolation. EPSS models the likelihood of a CVE being exploited on its own, and post-exploitation weaknesses are not exploited on their own.

Both scores are answering their question correctly. Both questions are the wrong ones here. The right question — is this being used against real systems? — is the one KEV answers, and it says yes.

Case 2: the highest severity, near the bottom for probability

JetBrains TeamCity, CVE-2026-63077. Unauthenticated remote code execution via the agent polling protocol, scored CVSS 9.8 by JetBrains as the CNA. EPSS: 10.72%. Added to KEV on 2026-08-05 with a remediation deadline of 2026-08-08 — a three-day window.

Read CVSS alone and this is a drop-everything emergency. Read EPSS alone and it looks like something to schedule. Both readings are incomplete, and the resolution is in the dates: this vulnerability is new. EPSS is trained on observable signals — exploit code in circulation, scanning traffic, published proofs of concept — and a recently disclosed flaw has had little time to accumulate any of them. A low EPSS on a fresh CVE means “not yet widely exploited”, not “unlikely to be”.

The Confluence entries are the same model looking at the other end of that curve. CVE-2022-26134 has been mass-exploited since June 2022 and now reads 100.00%. That is not a stronger vulnerability than the TeamCity one. It is an older one.

Case 3: the medium-severity flaw ransomware crews preferred

VMware ESXi, CVE-2024-37085. CVSS 6.8 from Broadcom. EPSS 25.95%. Neither number is alarming.

It is an Active Directory integration bypass: a member of a domain group named ESX Admins gains full host administrative access. Ransomware operators — Akira and Black Basta among them — used it in the wild, because a medium-severity bug that hands over every virtual machine on a host is worth more to them than a critical-severity bug in something obscure.

This is the limit of severity scoring as a priority signal. What a vulnerability is worth to an attacker depends on what it sits on top of, and a CVSS base score does not know that ESXi hosts your entire estate.

The standard does have somewhere to put that, which is worth knowing precisely because it is so rarely used. CVSS v3.1 defines environmental metrics — the confidentiality, integrity and availability requirements (CR/IR/AR) plus modified base metrics — for adjusting a score to the importance of the affected asset. CVSS v4.0 adds Value Density, which distinguishes a diffuse target from a concentrated one: a hypervisor is the textbook concentrated case. In practice almost nobody populates any of it. The number your scanner ingests and your policy fires on is the context-free base score, and that is the number that says 6.8.

The fourth disagreement: the scorers disagree with each other

There is a disagreement beneath the other three that is rarely discussed: a single CVE frequently carries more than one severity score, because the vendor (acting as CNA) and NVD score independently.

The gaps are small, but they straddle policy thresholds. A rule that escalates at 7.0 treats the ESXi flaw differently depending on which score your scanner ingested. And the TeamCity entry shows the more common situation for recent vulnerabilities: NVD has not scored it at all, so a pipeline keyed to NVD sees nothing where a 9.8 exists.

This is why our feed records the source of every CVSS value rather than a bare number. A score without its provenance is not a fact, it is a claim.

The column that changes the answer

Everything above is standard vulnerability triage, and for most teams it ends in the same place: apply the patch, priority set by the scores.

For every vulnerability on this feed, that option does not exist. Each one is confirmed exploited in a version that will never receive a fix — not delayed, not backlogged. Not coming.

Once patching is off the table, the three scores stop being a priority queue and become an argument for a different decision entirely: upgrade, replace, buy extended support where it exists, or isolate and document. The scores still matter — they tell you how much time you have — but none of them will ever resolve to “fixed”.

That is the column we think is missing from most vulnerability reporting. A CVE in supported software is a task. The same CVE in end-of-life software is a condition, and it does not improve on its own.

How to actually triage

A defensible order of operations, given all four signals:

1. KEV first, unconditionally. If it is on the CISA catalog, it is being exploited. Severity and probability become scheduling detail, not gating criteria. This is the rule that catches the FortiOS case every threshold-based policy drops.

2. Check whether a fix exists for your version before ranking anything. Priority is meaningless if the remediation is unavailable — a “patch within 30 days” ticket against a version that will never be patched is a ticket that quietly ages forever.

3. Use EPSS for what it is good at — ranking things that are not on KEV. That is where a probability forecast adds real information. Weight it by age: a low EPSS on a CVE disclosed last week is a statement about the model’s evidence, not about your risk.

4. Use CVSS last, and check its source. Ask which body assigned it, and whether the other one disagrees. If NVD has not scored it yet, the vendor’s number is the only one there is.

5. Ask what the software sits on top of. No score you actually receive carries this. A medium-severity flaw in your hypervisor outranks a critical one in a build tool, and ESXi is the case that proves it.

All twelve entries, with sources, affected versions, the exact reason no patch is coming, and live EPSS values, are on the Exploited & Unpatchable feed, which is also published as JSON. Every entry is verified by hand against the vendor advisory before publication, and removed if a backport ever appears.