One number, one precise claim

The Exploit Prediction Scoring System (EPSS) is a data-driven model maintained by FIRST (the Forum of Incident Response and Security Teams) through a dedicated special interest group. For every published CVE, it outputs a single number between 0 and 1:

The estimated probability that exploitation activity against this vulnerability will be observed in the wild within the next 30 days.

Every word in that sentence is load-bearing.

  • Probability, not severity. A worthless-to-attack bug in a critical system can score near zero; a mid-impact bug in a popular product can score 0.9.
  • Exploitation activity observed, meaning attempts detected by network sensors and honeypots, not confirmed breaches of your organization.
  • In the wild, somewhere on the internet. EPSS models the global attacker population, not your threat model.
  • Next 30 days, a rolling window. Scores are recomputed and republished daily for the entire CVE corpus, so a score is a snapshot, not a property of the CVE.

Where the number comes from

EPSS is a machine learning model trained on two kinds of data.

Ground truth: exploitation activity reported by sensor networks, IDS/IPS telemetry, and honeypots contributed by commercial and community partners. This defines what "was exploited" means for training.

Features: hundreds of observable attributes per CVE, including:

  • Public exploit code (Exploit-DB, Metasploit modules, GitHub proof-of-concepts)
  • Vendor and product, and how widely deployed they are
  • The weakness class (CWE) and CVSS base metrics
  • Listing in security tooling and scanner plugins
  • Mentions and discussion activity
  • Age of the vulnerability

The model learns which combinations of features historically preceded observed exploitation, then applies that to every CVE daily. When something changes (a Metasploit module lands, a proof of concept goes viral), the score can jump overnight. That volatility is a feature: it is the model reacting to new evidence.


Score vs percentile: do not confuse them

Each daily EPSS release carries two numbers per CVE, and mixing them up leads to bad decisions.

Value What it is Example reading
Score Absolute probability, 0 to 1 0.35 means roughly a 35% chance of observed exploitation within 30 days
Percentile Rank against all other scored CVEs 0.95 means the CVE scores higher than 95% of all CVEs

Because exploitation is rare (on the order of 6% of CVEs ever see it), the score distribution is extremely skewed. The median CVE scores in the low thousandths. Consequences:

  • A score of 0.10 sounds small but typically sits above the 90th percentile. It is not background noise.
  • A high percentile with a tiny score (say, 0.02 at the 88th percentile) still means exploitation is unlikely; the CVE is only notable relative to a very quiet crowd.

Use the score for risk decisions, because probabilities compose with impact and asset value. Use the percentile for communication, because "top 2% of all CVEs" lands better in a report than "0.14".


Sensible thresholds

There is no official cutoff; the right threshold is a trade-off between coverage and effort. Common starting points:

EPSS >= 0.5   Treat as "exploitation expected". Patch this cycle.
EPSS >= 0.1   Elevated. Patch soon on exposed or important assets.
EPSS <  0.01  Deprioritize unless KEV-listed or asset-critical.

Two operational notes. First, re-evaluate on movement, not just level: a CVE jumping from 0.02 to 0.30 in a week is telling you the ecosystem shifted. Second, thresholds only work if the score is visible at triage time; the daily CSV from FIRST is free, and platforms like vuln.mlab.sh display the current EPSS score and percentile on every CVE entry next to CVSS and the CISA KEV flag, including via JSON API for automation.


What EPSS does not tell you

EPSS is deliberately narrow, and its blind spots are exactly where teams misuse it.

No asset context. The model does not know the vulnerable server holds your customer database, or that it is airgapped in a lab. A 0.9 on an unreachable system may be irrelevant; a 0.05 on your internet-facing VPN concentrator may deserve attention anyway.

Not a severity measure. EPSS says nothing about impact. An information-disclosure bug can be heavily exploited (high EPSS) yet bounded in damage; pair the probability with CVSS impact metrics to get risk.

Weak on day zero. A brand-new CVE has few observable features, and pre-publication exploitation of an unknown vulnerability is outside the model entirely. EPSS complements, and cannot replace, vendor advisories and emergency response for breaking events.

Global, not targeted. The training signal comes largely from broad, opportunistic scanning and exploitation. A quiet, targeted exploit used by one espionage group against ten organizations may never move the score. If you are one of the ten, EPSS was not built to warn you.

Probabilistic, not binary. A 0.97 does not guarantee exploitation, and a 0.001 does not rule it out. It is a forecast, and forecasts are judged over portfolios, not single events.


Using it with KEV and CVSS

The three signals slot together cleanly because they answer different questions:

  1. CISA KEV is evidence: exploitation confirmed. KEV-listed plus present in your environment outranks everything else.
  2. EPSS is a forecast: it covers the gap before evidence exists, and the long tail KEV will never list.
  3. CVSS is impact: given exploitation, how bad does it get, and via which vector.

A one-line mental model: KEV overrides, EPSS orders the queue, CVSS and asset value size the response. Teams that adopt this typically find their urgent list shrinks by an order of magnitude while catching more of the CVEs that later show up in incident write-ups, which is the only benchmark that counts.

EPSS answers one question with unusual discipline: how likely is this CVE to be exploited soon, somewhere. Respect the question it answers, supply the context it lacks, and it becomes the best free prioritization signal you have.