Exploit Prediction Scoring System (EPSS)

The Exploit Prediction Scoring System (EPSS) is a daily-updated machine-learning model that estimates the probability a published CVE will be exploited in the wild within the next 30 days. An EPSS score is a calibrated probability from 0 to 1, paired with a percentile rank, and it exists because severity scores alone predict exploitation poorly.

EPSS scores cover every published CVE and are refreshed once a day, typically a minute or two after 13:30 UTC. The model answers a population question: across every system on the internet, how likely is anyone to attack this bug in the next month? It does not know whether your application ships the vulnerable code, calls the vulnerable function, or sits behind a control that blocks the attack.

Our position: EPSS is the best free signal for ranking how likely a CVE is to be exploited, and a poor gate on its own. Treat a CISA KEV listing as overriding any EPSS score. Use EPSS to order what remains. Then let reachability analysis decide what actually reaches your code. Never multiply EPSS by CVSS, and record the EPSS model version beside any threshold you set, because a model upgrade can move a score thirteenfold overnight.

An EPSS score is the estimated probability, from 0 to 1, that a CVE will see exploitation activity in the next 30 days. The percentile is a separate number: the share of all scored CVEs with an equal or lower score. Both come back from FIRST's public EPSS API, shown here with the envelope fields trimmed:

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2025-55182,CVE-2022-25883"

{
  "status": "OK",
  "total": 2,
  "data": [
    { "cve": "CVE-2025-55182", "epss": "0.997310000", "percentile": "0.999530000", "date": "2026-11-06" },
    { "cve": "CVE-2022-25883", "epss": "0.027610000", "percentile": "0.863360000", "date": "2026-11-06" }
  ]
}

CVE-2022-25883 is the regular-expression denial of service in the npm semver package. Its GitHub advisory rates it CVSS 7.5, High. Its EPSS score of 0.0276 means the model expects about a 2.8% chance of observed exploitation in the next 30 days. Its percentile of 0.863 means it outranks 86% of scored CVEs.

Read the probability, not the percentile. The EPSS distribution is extremely skewed toward zero. FIRST notes that a probability of 0.10 "currently sits around the 95th percentile". The mean score is about 2.8% and the median about 0.7%. On November 6, 2026, only 4,380 CVEs scored 0.5 or higher, according to an API query with epss-gt=0.5. An 86th-percentile label sounds alarming for a bug the model gives under a 3% chance.

An EPSS percentile can climb for weeks while the underlying score stays frozen. The API's time-series scope shows it for semver, trimmed here to three of its 30 daily entries:

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2022-25883&scope=time-series"

{
  "cve": "CVE-2022-25883", "epss": "0.027610000", "percentile": "0.863360000", "date": "2026-11-06",
  "time-series": [
    { "epss": "0.027610000", "percentile": "0.863240000", "date": "2026-11-05" },
    { "epss": "0.02761000", "percentile": "0.86152000", "date": "2026-10-21" },
    { "epss": "0.02761000", "percentile": "0.85844000", "date": "2026-10-07" }
  ]
}

The semver score did not move in 30 days. Its percentile rose from 0.858 to 0.863 because newly published CVEs mostly arrive with lower scores and push older ones up the ranking. A policy written as "fix everything above the 86th percentile" would have started flagging this bug on October 14, with no new evidence about it. Thresholds belong on the probability.

EPSS is calculated by gradient-boosted decision trees, implemented with XGBoost, trained on daily snapshots of every CVE. Each row is one vulnerability on one day. FIRST describes about 2,850 features in five families:

• Exploit code and offensive tooling
• Chatter: references on security-relevant sites, and how recent they are
• Vulnerability characteristics: CVSS vector metrics, tags derived from the description, vendor and product
• Age and reference volume
• Exploitation activity

The labels come from nearly a dozen data partners that run honeypots, IDS/IPS sensors, endpoint malware telemetry, and threat-intelligence feeds. FIRST reports a training corpus of roughly 120 million rows, more than 1.6 million daily exploitation events, and a typical training window of 12 months. Because most exploitation is never observed, the model is trained as a positive-unlabeled problem: a CVE with no recorded exploitation is unlabeled, not proven safe. The raw output is then calibrated, so that CVEs scored near 5% are exploited about 5% of the time in aggregate.

The production EPSS model is not retrained daily. Scores change day to day because inputs change: a proof of concept lands on GitHub, or a CVE picks up references. The model itself is retrained when its performance drifts, which so far has meant about once a year. EPSS also does not take past exploitation as a direct input. NIST and CISA researchers Peter Mell and Jonathan Spring spelled out the consequence in NIST CSWP 41: for vulnerabilities that have already been exploited, EPSS scores are systematically too low. That is the mechanical reason a KEV listing should override a low EPSS score.

EPSS began as academic research by Jay Jacobs, Sasha Romanosky, and colleagues, developed in 2018 and 2019 and published in 2021. It is stewarded by the EPSS Special Interest Group at FIRST, the Forum of Incident Response and Security Teams, the global association of incident response and security teams that also publishes CVSS. Today the model's training and infrastructure are provided by Empirical Security, which Jacobs co-founded. Every model version so far:

The dates come from FIRST's data page. As of November 2026, v5 is current. Empirical reports that v5 scored 0.633 on its ranking benchmark, against 0.514 for v4 on the same May 4, 2026 data, where random guessing scores 0.025. That is a vendor-reported number, and the exploitation telemetry needed to reproduce it is not public.

A new EPSS model rescores every CVE on the day it ships. We pulled the scores on either side of the v5 cutover with the API's date parameter:

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2025-55182,CVE-2022-25883,CVE-2024-21538&date=2026-06-14"
curl -s "https://api.first.org/data/v1/epss?cve=CVE-2025-55182,CVE-2022-25883,CVE-2024-21538&date=2026-06-15"

The figure plots these values, from the FIRST EPSS API:

CVE-2024-21538 is another ReDoS, in the npm cross-spawn process-spawning library, and its GitHub advisory also rates it CVSS 7.5. Both ReDoS scores jumped on the exact day the model changed. FIRST's data page warns that a jump on a version date reflects a methodology change, not a change in the vulnerability. Any automation that compared these scores to a fixed threshold changed its decisions along with the model.

The fix is cheap. The first line of the daily EPSS CSV is a comment naming the model version. Store that version beside every score you persist, and re-baseline thresholds when it changes. A dashboard that charts EPSS over time without the model version will show a cliff in June 2026 that no attacker caused.

EPSS reacts within a day or two of public exploit activity, but a newly published CVE starts near zero. React2Shell, the unauthenticated remote code execution flaw in React Server Components tracked as CVE-2025-55182 and rated CVSS 10.0, shows the lag.

The figure plots these values from the FIRST EPSS API, with KEV dates from CISA's KEV catalog data:

React2Shell was disclosed with patches on December 3, 2025. On its first scored day, EPSS put it at 0.46%. A team waiting for a 10% EPSS threshold would not have started until December 5, two days after disclosure and the same day CISA confirmed exploitation. FIRST says observed exploitation does not directly change the next day's score, by design. The December 5 jump most likely came from the model's other feature families, such as exploit code and chatter. For fresh disclosures, the vendor advisory and KEV are the signal. EPSS catches up afterward.

EPSS measures likelihood, CVSS measures severity, and CISA KEV records confirmed exploitation. They answer different questions and should not be blended into one number. FIRST is blunt about the most common mistake: "Multiplying EPSS by a CVSS score does not compute probability × severity and is never a good idea." CVSS is an ordinal ranking, not a calibrated magnitude, so the product has no meaning.

The verdict: KEV first, because confirmed exploitation beats any forecast. EPSS second, as a vulnerability prioritization input that orders the backlog and deflates CVSS-driven fire drills. Reachability third, to remove findings your code cannot trigger. CVSS last, to judge blast radius once something is both likely and reachable. Four npm CVEs show why severity alone misleads:

CVE-2023-42282 is the disputed ip package CVE that NVD rated 9.8. Its maintainer archived the repository in protest until GitHub lowered the advisory's severity. A CVSS-first queue puts it near the top; EPSS puts it below a 2% chance.

Aggregation is where calibrated EPSS probabilities earn their keep. FIRST's worked example takes 100 vulnerabilities each scored 0.05: the expected count exploited is five, and the chance that at least one is exploited is about 99.4%. Severity scores cannot do that arithmetic. The same math cuts the other way: a backlog of low scores is not a safe backlog.

EPSS is a population-level forecast about CVEs. Most of the risk in a dependency tree falls outside that frame.

EPSS knows nothing about your code. A 0.9 score on a library you install but never call is not an exposure for you. Many CVEs in a modern lockfile sit in transitive dependencies whose vulnerable functions application code never reaches. Socket's precomputed reachability marks about 60% of CVEs as unreachable from the dependency graph alone, and full application reachability typically filters about 80%.

EPSS scores CVEs, and malware does not get a CVE. By May 19, 2026, Socket had tracked the Mini Shai-Hulud worm across 1,055 compromised package versions in 502 packages, mostly on npm. The worm steals CI/CD and cloud credentials and republishes itself with stolen npm tokens. Malicious versions like these are reported as malware advisories, not CVEs, so EPSS never scores them. A supply chain program built on CVE scanning plus EPSS sorting has no signal at all for a malicious package.

EPSS inputs depend on a strained CVE pipeline. CVSS vector metrics are model features. In April 2026, NIST stopped enriching most CVEs in the National Vulnerability Database, leaving unenriched entries without NVD's CVSS and CPE data. Where NVD enrichment is missing, the model sees whatever the assigning CNA filed and nothing more. With 48,185 CVEs published in 2025, up 20.6% on 2024, thin records are common.

In Socket, the alert view shows a CVE's EPSS score and percentile, and alert CSV exports include an EPSS column. EPSS ranks known CVEs. It does not replace analyzing what a new package version actually does when it installs.

The strongest EPSS claim is calibration, and that claim cannot be independently audited. Exploitation labels come from partners whose agreements prohibit redistribution, so FIRST does not release the training data, and the operational pipeline is not published. Benchmarks like the v5 figure come from the team that trains the model. NIST CSWP 41 has started to measure EPSS from the outside, but its authors note their own error margin is unknown for lack of public exploitation data. Until exploitation telemetry is shared openly, EPSS is a forecast whose accuracy the industry takes on trust. Use it to sort the queue. Do not let it be the reason a KEV-listed bug went unpatched.