Most vulnerability queues we have seen are ordered, explicitly or by habit, on one number: the CVSS base score. Everything scored 9.0 and up goes to the top, the 7-to-9 band is the weekly work, and the rest waits. It is a defensible-looking policy and it is the wrong tool for the job it is being asked to do. CVSS base was never a measure of what an attacker will do next. EPSS is, or at least it is an honest attempt at one, and the two answer different questions. Confusing them is how a team ends up patching a critical that no one will ever touch while a medium is being exploited against them the same week.
What CVSS v3.1 base actually measures
The CVSS base metric group describes intrinsic properties of a vulnerability: how it is accessed, how hard it is to exploit, what privileges it needs, and what happens to confidentiality, integrity, and availability if it is exploited. Read the v3.1 specification and the framing is explicit. Base is meant to be constant over time and across environments. It says nothing about whether exploitation is happening, whether a public exploit exists, or whether the vulnerable component is even reachable in your deployment. Those belong to the temporal and environmental metric groups, which almost nobody fills in.
So a bare CVSS base is a severity-if-exploited figure. A 9.8 means “if this is exploited, the impact is near-total and the preconditions are minimal.” It is a real and useful statement. It is not a statement about likelihood, and using it to order a queue treats it as one. CVSS v4.0 tries to narrow this gap by making the supplemental and threat metrics more prominent, but the base score in isolation still carries the same meaning it always did, and the base score in isolation is what most tooling surfaces.
What EPSS measures
The Exploit Prediction Scoring System answers the other question directly. It produces, for a given CVE, a probability that the vulnerability will be exploited in the wild in the next 30 days, and it updates that probability daily against observed exploitation data. It is a model, trained on features of the CVE and on real exploitation signals, and its documentation is candid about being a prediction rather than a fact.
The single most useful thing the EPSS data has established is structural, not per-CVE: the large majority of published CVEs are never observed being exploited at all. Exploitation is concentrated in a small fraction of them. That is the finding that should reshape a triage queue, because it means “patch everything scored high, in score order” spends most of its effort on vulnerabilities that will never be attacked, while the genuinely active minority waits its turn behind them.
Where the two numbers disagree
The disagreement is the entire point, so it is worth being concrete about the shapes it takes.
- High base, low probability. A CVSS 9.8 in a library or product feature that is hard to reach, unattractive to operators, or simply never weaponised. The base score screams; the EPSS probability sits near the floor and stays there for months. These dominate the top of a CVSS-ordered queue and deserve to be nowhere near it.
- Moderate base, high probability. A CVSS 6.5 that is trivial to automate, sits in an internet-facing component, and shows up in commodity exploitation within days. EPSS flags it; a base-ordered queue buries it in the medium pile. This is the case that gets organisations hurt.
- Both high. The comfortable case where the policy and the reality agree. It exists, and it is why base-ordering has survived as long as it has. It works right up until it quietly does not.
The floor that neither score sets
Before either score comes into it, there is a binary signal that outranks both. The CISA Known Exploited Vulnerabilities catalog lists vulnerabilities with confirmed, observed exploitation. A CVE on the KEV is not a prediction that it might be attacked. It is a record that it is being attacked. That is a stronger statement than any EPSS probability and any CVSS base, and it should be the first gate in the queue: if it is on the KEV, it is patched now, regardless of what its base score says.
We wrote up CitrixBleed 2 (CVE-2025-5777) earlier this year as an example of exactly this. Its impact was scored as information disclosure, which understated it, but the operationally decisive fact was that it landed on the KEV because it was being exploited against real deployments. No amount of scoring debate mattered next to that one bit of ground truth.
The order we would actually run the queue in
Put the three signals in the order that matches what each one knows.
- KEV first. Confirmed exploitation is the strongest signal available. If a vulnerability in your environment is on the catalog, it goes to the front, full stop.
- EPSS to rank the rest. For everything not on the KEV, the probability of near-term exploitation is the right ordering key, because it is the closest available answer to “what will be attacked next.” Set a threshold, revisit it against your own tolerance, and let it float the trivial-to-automate mediums above the unreachable criticals.
- CVSS base as an input, not the policy. Base still matters, as one component of the decision: it tells you how bad the day is if the thing you deprioritised turns out to be the exception. Use it to weight impact, and to decide how much margin to leave, not to set queue order on its own.
- Environmental reality on top of all of it. A high-probability vulnerability in a component you do not run, or one that is unreachable behind other controls, is not your emergency. This is the environmental metric group doing the job it was designed for, and it is the step that no external score can take for you.
Editor’s note: The teams we have watched get this wrong were rarely lazy. They were auditable. “Patch all criticals within N days” is a clean line to draw for a regulator or a board, and CVSS base gives you a criticals list without any judgement calls. EPSS-plus-KEV asks the queue owner to defend why a 9.8 is waiting behind a 6.5, and defending that in a report is harder than sorting by a number. The better policy costs you a sentence of explanation per exception. It is worth the sentence.
What EPSS does not fix
None of this makes EPSS a replacement for judgement. It is a model, and it is honest about the limits of that. It predicts observed, commodity-style exploitation well and targeted activity against a specific organisation poorly, because targeted activity does not show up in the broad signals it trains on. It can be low on the day before a proof of concept drops and high the day after, which means a queue built on it has to be re-read daily, not set once. And it says nothing about your environment; a 90th-percentile probability against software you do not deploy is somebody else’s problem. Our reference index at descriptions.securescout.com/reference.html keeps the primary sources for the scoring systems in one place, because the fastest way to misuse any of these numbers is to read the score without reading what it was built to mean.
The short version is the one we keep repeating to anyone who will listen. CVSS base tells you how bad it would be. EPSS tells you how likely it is. KEV tells you it already happened. A patch queue that only knows the first of those three is optimising for the wrong question, and the cost of that shows up as the medium-severity vulnerability that was being exploited while the team was busy with a critical that no one ever touched.