Exploit Prediction Scoring System (EPSS)

What is EPSS?

EPSS is an exploit prediction model that answers one question: how likely is this CVE to be exploited in the wild in the next 30 days? The FIRST EPSS Special Interest Group maintains it, and Empirical Security provides, in FIRST's words, "all of the data, data science, infrastructure and support for the daily scores."

The output is a probability of exploitation between 0 and 1, usually reported as a percentage, produced for every publicly disclosed CVE. EPSS v5 covers more than 318,000 of them. A score close to zero is not a blank: FIRST describes a near-zero estimate as "a prediction, not a data gap."

What the metric is not matters just as much. It does not describe impact, it does not know your assets, and it does not account for compensating controls. FIRST says so plainly in the EPSS FAQ: "EPSS is not a complete risk score." The model supplies the likelihood of exploitation and nothing else. It also works only on vulnerabilities with an assigned public CVE ID, so a flaw in your own first-party code never gets a score at all.

How the EPSS model works

The model learns correlations between the published characteristics of a vulnerability and the exploitation activity observed afterward. FIRST describes the method as training "on historical data" and evaluating "against held-out vulnerabilities over held-out time periods," so performance is measured on activity the model never saw.

What data feeds the model

Two streams go in. The first describes the vulnerability itself. One detail matters if you use both metrics: the model "uses all individual CVSS metrics as input features (scores are ignored)." Attack vector and complexity inform the prediction; the composite severity number does not.

The second stream is observed exploitation activity, supplied by partners whose raw data FIRST cannot always redistribute. Both refresh daily, which is why an EPSS reading moves without the vulnerability changing. FIRST checks its own work by comparing scores published 30 days earlier against the exploitation seen since.

Scores and percentiles

Every CVE gets two numbers: a probability and a percentile. The percentile orders that probability against every other scored CVE. As Romanosky and Jacobs put it in a post for FIRST, "the percentile is the proportion of all values less than or equal to the current rank."

A worked example from our own database: on November 3, 2026, the vm2 record carried an EPSS value of 1.04% at the 63.79th percentile. A probability near 1% sounds negligible until the percentile tells you that roughly 64% of all scored CVEs sit at or below it. For scale, FIRST puts the 90th percentile at about 0.04 — a 4% probability. The absolute number and the relative position are two readings of the same day's output, and the percentile is the one that says where a CVE stands in the queue.

What changed in EPSS v5

Version 5, released by Empirical Security in 2026, replaced version 4. The published changes are narrower than the version bump suggests, and worth stating precisely rather than paraphrasing:

• Model optimization: refined techniques for ranking vulnerabilities by likely exploitation.

• Probability calibration: scores now track observed likelihood more closely, which matters for teams feeding EPSS into quantitative risk models.

• Exploit code intelligence: the upstream classifier is better at identifying published repositories and artifacts that signal elevated risk.

• Incremental data improvements: smaller feature and data-feed changes, which Empirical Security does not itemize.

Empirical Security reports the result as a 23% improvement, measured on the same data: version 4 scored 0.514 on May 4, 2026, and version 5 scored 0.633, on a scale where a random guess lands near 0.025 and a perfect model reaches 1.0.

EPSS at Fluid Attacks

We treat EPSS as one input among several, never as the number that decides a queue. Here is how vulnerability prioritization works in our platform, and where the metric stops being useful.

Where it sits among seven prioritization attributes

Our documentation defines the attribute as "the probability that attackers will exploit a vulnerability in the next 30 days." It is one of seven prioritization attributes a security team can weight: Transitivity, Use, KEV, % EPSS, Fixing cost, VLAI Severity and Reachability.

The mechanic is worth stating because few vendors publish it: CVSS v4.0 scores are adjusted by up to 2 points for the priority score according to these attributes, while the displayed severity value stays untouched. Priority and severity stay separate fields on purpose, so a team reordering its queue never loses sight of how bad a finding is. Fluid Attacks is listed among the vendors that support the metric in FIRST's public directory.

The priority score blends EPSS with other attributes.

What the signals look like side by side

Two records from our database, read on the same day, show why one number is not enough.

EPSS scores are recalculated daily. These are the values recorded in Fluid Attacks' database on November 3, 2026, not permanent scores.

The exploitation signals in the Jenkins record, read on November 4, 2026.

The Jenkins denial of service carries a High base score and a sub-1% probability of exploitation. The vm2 sandbox breakout is Critical and still sits near 1%. Severity tells you the ceiling; EPSS tells you the odds; neither tells you whether the vulnerable code runs in your application. That last question is what reachability analysis answers.

Teams that tune the criteria remediate more

Our State of Attacks 2026 report, built on data collected between January 1 and December 31, 2025, found that clients who set prioritization criteria in a custom arrangement had a mean remediation rate of 64.4%, against 34% for those on the default. Around 2% of clients had done it.

The honest reading: this is an association, not a demonstrated cause. Risk-based vulnerability management here covers fixing cost, dependency usage, transitivity, EPSS and KEV together, so no single attribute earns the credit. What it does suggest is that teams which think about their prioritization order tend to be the ones that act on it.

What we do not let the score tell us

Two limits we apply to ourselves.

A low score is not a clean bill of health. EPSS is a population-level estimate for the next 30 days, not a statement about your instance. The Jenkins record above reads 0.56%, which means the model sees no current exploitation signal. It does not mean the vulnerability is safe, and it does not survive contact with a KEV listing.

Maximum severity and a low predicted likelihood in the same record.

Detection is still the bottleneck, not prioritization. In Fluid Attacks' benchmark of 36 third-party AppSec tools against a dataset of 1,201 vulnerabilities worth 461,500 CVSSF units, our own scanner was the strongest automated engine at 22.7% recall and 99% precision — but only 8.8% CVSSF recall. A pentester reached 89.6% recall and 98.9% in CVSSF terms. Prioritizing well among the findings you have does not recover the risk exposure no scanner found. That is why our Advanced plan pairs AI and scanners with pentesters.

Never read the score alone

Our analysis of how the Fluid Attacks Database connects CVEs to fixes and standards puts it in one line: read the signals together, not the base score alone. The inverse holds too — a low probability never overrules a CVE already in KEV, because one forecasts and the other records.

EPSS, CVSS and CISA KEV are not alternatives

These three get compared as if a team had to pick one. They measure different things at different moments; a working process uses all three.

Fluid Attacks' analysis of how severity ratings diverge across tools frames the split the same way: CVSS tells you about potential impact, EPSS tells you about likelihood, and CISA's known exploited vulnerabilities catalog tells you what is already being exploited. CISA builds that catalog on public criteria — an assigned CVE ID, reliable evidence of active exploitation, and clear remediation guidance — which is why a KEV entry outranks a forecast.

The sequence matters more than the ranking. In practice, vulnerability prioritization starts with the KEV catalog, because confirmed exploitation removes the question entirely. What is left gets sorted by exploitation probability, and the CVSS score decides how hard to push on the ones that score closely. Reversing that order is how a team ends up patching a theoretical Critical while a Medium with a published exploit sits open.

Plot severity against probability and four quadrants appear. Bottom-left is the lowest priority. Top-left means likely exploitation with limited individual impact, which still deserves attention because those flaws get chained. Bottom-right means high impact with low current probability: monitor it, because the probability moves. Top-right is where vulnerability remediation starts.

None of the three, on its own, constitutes risk-based vulnerability management. FIRST's own guidance on localizing a score lists three checks — presence, reachable code and consequence — and notes that "EPSS has no visibility into your asset inventory or compensating controls." A missing factor in any of the three lowers the urgency whatever the number says.

Why EPSS matters: the arithmetic of alert fatigue

Severity-only prioritization fails for a reason you can calculate. Researchers score a strategy on how it sorts vulnerabilities later exploited (true positives) from those that were not (false positives), and those correctly delayed (true negatives) from those wrongly delayed (false negatives). Three figures follow.

• Effort: the share of all vulnerabilities the strategy prioritizes.

• Efficiency: TP / (TP + FP) — the share of what you fixed that was actually exploited. Analogous to precision in F-scores.

• Coverage: TP / (TP + FN) — the share of exploited vulnerabilities you caught. Analogous to recall.

FIRST frames threshold selection as the same tradeoff: a lower cut catches more exploitation and means more remediation.

Run the numbers on the common “fix everything at CVSS 7 or above” policy. Fluid Attacks’ review of severity ratings reports that, on FIRST’s October 2023 data, it yields an efficiency of roughly 4%: about four of every hundred vulnerabilities remediated under it were exploited within 30 days. The policy prioritizes 57.4% of CVEs and covers 82.2% of exploited ones; an EPSS threshold of 10% prioritizes 2.7%, covers 63.2% and reaches 65.2% efficiency. The same analysis found that approximately 0.9% of CVEs reported in 2024 were actively weaponized, and roughly 0.2% were used in ransomware or by advanced persistent threat groups.

Fixing everything at CVSS 7+ covers 82.2% of exploited CVEs at 4.0% efficiency. An EPSS 10%+ threshold covers 63.2% at 65.2%. Source: FIRST, October 2023 data.

FIRST counts about 61,000 CVEs published in the last 12 months and tracks exploitation on 1.5% to 3% of them in any 30-day period. A severity cut that sweeps in 57.4% of CVEs is sorting almost entirely by findings that will never be touched.

Most published vulnerabilities, including most rated High or Critical, carry very low exploitation probabilities, so a severity cut-off sweeps in tens of thousands of findings that exploitability data would skip. Sorting by EPSS does not shrink a backlog — it changes which part of it gets your week.

That is where EPSS earns a place in vulnerability remediation planning rather than in reporting. A severity threshold is a policy you write once and then defend; an exploitability signal keeps arriving.

How to use EPSS without a universal threshold

There is no threshold that works for everyone, and FIRST says so. Setting one is, in its guidance on using EPSS, "a very localized effort" best reached by trial and revision. It also warns against cutoffs picked by intuition: a 50% threshold sounds balanced and actually "deprioritizes the 98.8% of all published vulnerabilities."

If you are migrating from a severity policy, FIRST publishes translations rather than a recommendation. Acting on CVSS Critical lands near the 90th percentile, about a 4% probability, for roughly the same population size. Acting on High and above — close to the top 48% of published vulnerabilities — maps to around 0.008, or 0.8%. FIRST calls these a starting point, not an endorsement of the CVSS bands behind them.

The second rule is to treat the probability as a continuous variable rather than a label; FIRST says it is "best used as a continuous variable in models and calculations." Scores move with the signals the model sees, sometimes sharply. Log4Shell is the documented case.

Historical scores from FIRST's Log4Shell case study, produced by EPSS v1.

FIRST is careful about what this shows, and so are we. For a vulnerability that obvious, the organization writes, "there is little benefit from a scoring system like EPSS" — the urgency was clear without it, and FIRST treats Log4Shell as an outlier rather than a test of the model. What the series does illustrate is the mechanic: as public references and exploit code appeared, the score climbed, fell back, and climbed again. A score is a reading for one day, not a verdict.

So the practice that works is unglamorous. Pull scores from FIRST's public data endpoints daily rather than storing them. Check the KEV catalog first: FIRST's own rule of thumb for a recent addition is to "treat it as actively exploited and prioritize accordingly, regardless of EPSS score." Weigh the rest against whether the vulnerable code is reachable and the asset exposed. Then decide.

Conclusions

EPSS answers a narrow question well: of the CVEs published so far, which are likely to be exploited next month? That is a different question from how severe a vulnerability is, and treating the two as interchangeable is how teams spend a quarter on findings nobody will touch.

The limits of EPSS are as clear as its value. The model does not know your environment, it scores only vulnerabilities with public CVE IDs, and its output changes daily. Used as one signal among severity, confirmed exploitation, reachable code and asset context, it sharpens a remediation queue. Used alone, it is just a different number to be wrong about.

If you take one rule from this page, make it the sequencing: check the KEV catalog first, read the EPSS percentile rather than the raw probability when comparing findings, and let reachable code break ties.

Frequently asked questions

What does an EPSS score actually mean?

It is the estimated probability that a publicly disclosed vulnerability will be exploited in the wild within the next 30 days, on a scale from 0 to 1. It is not a severity rating, not a measure of impact, and not a guarantee either way. Empirical Security regenerates the scores daily, so a value is a reading for a given date rather than a fixed property of the CVE.

What is the difference between EPSS and CVSS?

CVSS scores the intrinsic severity of a vulnerability: how bad exploitation would be, based on attack vector, complexity and impact. EPSS estimates how likely exploitation is in the next 30 days, based on machine learning trained on observed exploitation activity. One describes the ceiling, the other the odds. FIRST maintains both, and they are designed to be read together.

Can a vulnerability have a low EPSS score and still be dangerous?

Yes. CVE-2026-47208, a sandbox breakout in vm2, carried a CVSS v3.1 base score of 10.0 and an EPSS value of 1.04% in Fluid Attacks' database on November 3, 2026. A low probability also never overrides a CVE listed in CISA's KEV catalog, because that catalog records confirmed exploitation while the model only forecasts it.

Is there a good EPSS threshold?

No universal one exists. FIRST calls threshold-setting a very localized effort and warns that an intuitive 50% cut deprioritizes 98.8% of all published vulnerabilities. As a migration reference it maps a CVSS Critical policy to roughly the 90th percentile, about 4%, and a CVSS High and above policy to around 0.8%. Raising the cut improves efficiency and reduces effort, but lowers coverage.

Does Fluid Attacks use EPSS to prioritize vulnerabilities?

Yes, as one of seven prioritization attributes alongside Transitivity, Use, KEV, Fixing cost, VLAI Severity and Reachability. These attributes adjust the CVSS v4.0 score by up to 2 points for priority without changing displayed severity. In our State of Attacks 2026 report, clients who customized this arrangement showed a mean remediation rate of 64.4%, against 34% for those on the default.

Fix what is likely to be used against you

Our AI, scanners and pentesters report every finding with its EPSS probability, its KEV status and whether its code is reachable, so your team fixes what attackers can reach. Start free trial · Contact us.