EPSS Basics and How to Check Scores
Published: August 30, 2026
Introduction
A very large number of CVEs are published, and responding to all of them with the same priority is not practical.
CISA's KEV Catalog identifies vulnerabilities that have been exploited in real-world attacks. However, vulnerabilities that are not in the KEV Catalog may still be likely to be exploited in the future.
EPSS provides another input for assessing the likelihood of exploitation in the near future.
This article explains what EPSS means, how to interpret and retrieve its scores, the role of FIRST, how the scores are calculated, and how earlier EPSS models differ.
What is EPSS?
EPSS stands for Exploit Prediction Scoring System. It estimates the probability that a published CVE will be exploited in real-world attacks within the next 30 days.
A score from 0 to 1 is published daily for each CVE.
For example, an EPSS score of 0.05 means that, among many vulnerabilities
with similar characteristics, exploitation activity is expected to be
observed for approximately 5% of them within the next 30 days.
EPSS is available from FIRST, with access methods summarized on FIRST's Get the Data page.
FIRST and EPSS
EPSS is maintained by the FIRST EPSS Special Interest Group (EPSS SIG). Empirical Security provides the data processing and infrastructure required to generate the scores, which are published free of charge.
FIRST stands for Forum of Incident Response and Security Teams. It is an international nonprofit organization whose members include CSIRTs and security organizations from around the world.
A CSIRT is an organization or team that responds to security incidents such as cyberattacks and data breaches. FIRST supports information sharing among CSIRTs, cooperation in incident response, and the development of security standards.
In addition to EPSS, FIRST manages CVSS, which assesses the technical severity of vulnerabilities.
Relationship to MITRE and CNAs
The roles of CNAs, MITRE, and FIRST in vulnerability management can be summarized as follows:
| Organization | Primary role |
|---|---|
| CNA | Assigns CVE IDs to vulnerabilities within its scope and publishes CVE Records |
| MITRE | Operates the CVE Program Secretariat and infrastructure and serves in higher-level CNA roles |
| FIRST | Manages systems such as CVSS and EPSS for evaluating and using published vulnerability information |
A CNA can assess a vulnerability with CVSS, which is managed by FIRST, and include the values in a CVE Record. EPSS uses information from published CVEs, including CVSS information, as input data.
EPSS score and percentile
EPSS primarily publishes two values for each CVE:
| Field | Meaning |
|---|---|
epss |
Estimated probability that exploitation activity will be observed within the next 30 days |
percentile |
Proportion of CVEs whose EPSS score is less than or equal to this CVE's score |
EPSS score
The EPSS score is an absolute estimated probability.
0.01: 1%0.10: 10%0.50: 50%
Because exploitation is uncommon across the overall vulnerability population, most CVEs have EPSS scores close to zero. A score that appears numerically low may therefore still be high relative to other CVEs.
Percentile
The percentile represents the CVE's relative position among all scored CVEs.
For example, a percentile of 0.95 means that the CVE's EPSS score is in
approximately the top 5% of all CVEs.
The EPSS score is an exploitation probability, while the percentile is a relative ranking. Reviewing both can help when narrowing the number of vulnerabilities selected for action.
How to retrieve EPSS scores
EPSS scores are available through the API, a daily CSV file, and historical data on GitHub. All three are free and require no registration.
Query a specific CVE through the API
Use the FIRST EPSS API to retrieve the current score for a specific CVE.
The endpoint, parameters, and response format are documented in FIRST.Org REST API: GET /epss.
The main fields in the response are shown below:
{
"cve": "CVE-2021-44228",
"epss": "0.999990000",
"percentile": "1.000000000",
"date": "YYYY-MM-DD"
}
Values change daily, so this example illustrates only the response format.
Separate multiple CVEs with commas:
Add date to request scores from a past date:
Use scope=time-series to retrieve the most recent 30-day history:
The main EPSS API parameters are:
| Parameter | Description |
|---|---|
cve |
Filters by CVE ID; separate multiple values with commas |
date |
Specifies a past date in YYYY-MM-DD format |
days |
Filters by the number of days since a score was added to the EPSS database |
epss-gt |
Returns EPSS scores greater than or equal to the specified value |
epss-lt |
Returns EPSS scores less than or equal to the specified value |
percentile-gt |
Returns percentiles greater than or equal to the specified value |
percentile-lt |
Returns percentiles less than or equal to the specified value |
q |
Searches CVE IDs by partial match |
scope=time-series |
Returns scores and percentiles for the most recent 30 days |
For example, the following queries return CVEs with an EPSS score of at least 0.5 or a percentile of at least 0.9:
The API is intended for individual CVEs or small batches. It is not recommended for retrieving every CVE one at a time.
The FIRST API also exposes the following public methods:
| Method | Information returned |
|---|---|
/teams |
Names, countries, contact details, and scopes of FIRST-registered CSIRTs |
/news |
FIRST news, articles, and press releases |
/channels |
News categories, URLs, and RSS feeds |
/countries |
Country names, country codes, and regions |
/epss |
EPSS scores, percentiles, and historical scores by CVE |
The /teams, /news, /channels, and /countries methods provide FIRST
organizational and communications information. Use /epss for vulnerability
EPSS data.
Download the daily CSV
Use the daily CSV file to retrieve the latest scores for all CVEs at once.
The URL, fields, and usage guidance are documented under Daily CSV on FIRST's Get the Data page.
The CSV contains three fields:
cve: CVE IDepss: EPSS scorepercentile: percentile
The daily CSV is more suitable than the API for bulk matching against scanner results or importing scores into a database.
Retrieve historical scores from GitHub
Empirical Security's official GitHub repository stores compressed daily CSV files containing historical scores.
Files use the following path format:
For example, scores from March 7, 2023 are stored at:
How EPSS scores are calculated
EPSS v5, which entered production on June 15, 2026, uses gradient-boosted trees implemented with XGBoost (FIRST, "How EPSS Works", accessed August 29, 2026).
For each vulnerability, approximately 2,850 input features are created from the information described below. The model learns the relationship between these input features and the training label, observed exploitation activity.
The approximately 2,850 input features fall into four broad categories.
Features
Exploit code and offensive tooling
- Public exploit code and proofs of concept
- Inclusion in exploit frameworks such as Metasploit
- Inclusion in tools that can be used for attacks or testing, such as Nuclei templates
- Usage of and attention to exploit-code repositories on GitHub
The model considers not only whether a proof of concept exists, but also where it was published and whether it has been made readily usable.
Security community discussion
EPSS uses information about which vulnerabilities are mentioned by security-related sites, when they are mentioned, and how much attention they receive. A recent increase in discussion may indicate growing attacker interest.
Vulnerability characteristics
- Individual CVSS metrics such as Attack Vector, Attack Complexity, and Privileges Required
- Confidentiality, integrity, and availability impacts
- Characteristics extracted from vulnerability descriptions
- Vendor and product information
EPSS does not use the aggregate CVSS score directly. Instead, it uses the individual metrics that make up CVSS as features.
CVE age and reference information
EPSS uses the time elapsed since a CVE was published and the volume of references associated with it. Even older vulnerabilities may become likely targets as information accumulates and attack tools incorporate them.
Training label
Observed exploitation activity
Observed exploitation activity is not one of the approximately 2,850 input features. During training, it is the label indicating whether exploitation of each CVE was observed on a given day. Sources include:
- Malware detected on endpoints
- Attacks observed by honeypots
- Exploitation attempts detected by IDS and IPS products
- Threat-intelligence feeds and catalogs of exploited vulnerabilities
The recorded activity does not necessarily represent successful compromise. Traffic blocked by an IPS and attacks directed at honeypots still provide evidence that attackers targeted the vulnerability.
Recent exploitation activity is also not fed directly into the daily score. Observed exploitation data is used to train the model, while daily scores are calculated from the four categories of input features available at that time.
How the model is trained
EPSS pairs the vulnerability information known on a particular day with the exploitation activity observed for that day.
It uses a point-in-time architecture that records only information actually available on each date, preventing information learned in the future from leaking into historical training data.
The current model description states that a typical 12-month history produces a training matrix of approximately 120 million rows and 2,850 columns. Each row represents one CVE on one day, with a training label indicating whether exploitation was observed that day.
However, failure to detect an attack through endpoint products, honeypots, IDS, or IPS does not prove that the vulnerability was not exploited. Some attacks may not have been observed.
EPSS v5 therefore uses Positive-Unlabeled Learning (PU Learning). Data with observed exploitation is treated as Positive, while data without observed exploitation is treated as Unlabeled, meaning the exploitation status is unknown. The model does not assume that all unobserved cases are negative and accounts for the possibility that the unlabeled data includes exploitation that was not observed (FIRST, "How EPSS Works", accessed August 29, 2026).
What is published about the model
EPSS publishes the following information:
- Types of data used
- Feature categories
- Machine-learning algorithm
- Training and evaluation methods
- Model performance and limitations
- Calculated scores for each CVE
The following are not fully public:
- The trained model itself
- All training data
- Nonpublic observations supplied by data partners
- The complete code needed to reproduce production scores
The mechanism and evaluation approach can therefore be reviewed, but a third party cannot fully reproduce the official score from the same inputs.
Previous EPSS models
FIRST's Research page collects papers and presentations about earlier EPSS models.
| Version | First used | Main method and changes | Documentation |
|---|---|---|---|
| v1 | April 14, 2021 | Logistic regression regularized with Elastic Net; 16 features; predicted exploitation within 12 months of publication | Exploit Prediction Scoring System (2021) |
| v2 | February 4, 2022 | Switched to XGBoost; expanded to 1,164 features; changed prediction horizon to the next 30 days | Enhancing Vulnerability Prioritization: Data-Driven Exploit Predictions with Community-Driven Insights (2023), "Evolution of EPSS" |
| v3 | March 7, 2023 | Continued with XGBoost; expanded to 1,477 features; improved data sources and parameter tuning | Enhancing Vulnerability Prioritization: Data-Driven Exploit Predictions with Community-Driven Insights (2023) |
| v4 | March 17, 2025 | Updated model and data | FIRST presentations; no dedicated peer-reviewed paper is listed on the Research page |
| v5 | June 15, 2026 | XGBoost, Positive-Unlabeled Learning, and approximately 2,850 features | FIRST's current How EPSS Works page; no dedicated peer-reviewed paper is listed on the Research page |
As of publication, the FIRST Research page does not list a dedicated peer-reviewed paper for v4 or v5. V4 is described in presentations, while v5 is described in FIRST's current documentation and presentations.
The score periods in the GitHub repository are:
| Version | Score period on GitHub |
|---|---|
| v1 | April 14, 2021–February 3, 2022 |
| v2 | February 4, 2022–March 6, 2023 |
| v3 | March 7, 2023–March 16, 2025 |
| v4 | March 17, 2025–June 14, 2026 |
| v5 | June 15, 2026–present |
Starting with v2, the first comment line in each CSV records the model version and publication date.
Differences among CVE, CVSS, KEV, and EPSS
CVE, CVSS, KEV, and EPSS represent different information.
| Item | What it tells you |
|---|---|
| CVE | Which vulnerability is being discussed |
| CVSS | The vulnerability's technical severity |
| KEV | Whether exploitation in real-world attacks has been confirmed |
| EPSS | The likelihood of exploitation within the next 30 days |
A vulnerability may have a high CVSS score and a low EPSS score, or a modest CVSS score and a high EPSS score. Technical severity and the likelihood that attackers will target a vulnerability are not the same.
KEV represents confirmed past exploitation, while EPSS is a forecast for the next 30 days. A low EPSS score for a KEV-listed vulnerability is not necessarily contradictory. However, when recent exploitation has been confirmed, that evidence should take priority.
Using EPSS in vulnerability management
FIRST's "Using EPSS" explains how to combine EPSS with product presence in your environment, attacker reachability, the consequences of exploitation, and confirmed exploitation sources such as CISA KEV. Based on that guidance, EPSS can be used in a workflow such as:
- Identify CVEs detected by a vulnerability scanner.
- Check whether they are listed in the KEV Catalog.
- Review their EPSS scores and percentiles.
- Review their impact using CVSS and vendor advisories.
- Determine whether affected products are present in your environment, reachable externally, and have fixes available.
- Combine these inputs to prioritize the response.
For example, when many vulnerabilities share the same CVSS score, KEV status and EPSS can help narrow the set that should be investigated and addressed first. FIRST describes how to combine EPSS with environment-specific data in "Combining EPSS with other signals".
Simply multiplying EPSS and CVSS to create a custom risk score is not recommended. EPSS is a probability, while CVSS is not a probability of the same kind, so their product has no clear statistical meaning. FIRST describes this misuse as "Score Laundering" under "Common misuses, misapplications, and misunderstandings".
Considerations when using EPSS
A low EPSS score does not mean safe
EPSS is a forecast, not a certainty. A vulnerability with a low score may still be exploited, while a high score does not guarantee exploitation. FIRST also warns against interpreting a low probability as safe in "Common misuses, misapplications, and misunderstandings".
EPSS does not assess your environment
EPSS does not know whether an affected product is present in your environment, whether a vulnerable function is in use, or whether the system is reachable from the internet.
A high-scoring vulnerability that is not present in your environment does not require remediation there. Conversely, a low-scoring vulnerability on a critical internet-facing system may warrant priority investigation. FIRST describes the checks for Presence, Reachability, and Consequence under "Localizing the score".
EPSS is not a real-time attack feed
EPSS does not provide real-time attack notifications. Daily score changes reflect new inputs such as published exploit code, inclusion in offensive tools, and security-community discussion.
When actual exploitation is confirmed, prioritize that evidence rather than waiting for EPSS to change. FIRST explains that recent exploitation is not a direct daily scoring input and that confirmed exploitation evidence should take precedence under "Common misuses, misapplications, and misunderstandings".
Take care when comparing scores across model versions
A model-version change can significantly alter the score for the same CVE. When analyzing long-term trends, check the dates on which the model changed. FIRST notes this effect under "Historical data" on the Get the Data page.
Summary
EPSS estimates the probability that exploitation activity for a published CVE will be observed within the next 30 days.
- The FIRST EPSS SIG maintains EPSS.
- EPSS assigns each CVE a probability from 0 to 1 and a percentile.
- Scores are available free through the API, daily CSV, and GitHub.
- The current model uses XGBoost and learns from extensive vulnerability information and observed attack data.
- The calculation methodology is described publicly, but the model and data required to reproduce official scores fully are not public.
- Historical scores are stored on GitHub.
- EPSS should be combined with CVSS, KEV, and information about your own environment.
CVE is a vulnerability identifier, CVSS describes technical severity, KEV records confirmed exploitation, and EPSS estimates near-term exploitation likelihood.
EPSS should not determine whether to respond by itself. It is best used to narrow a large vulnerability population to the items that should be examined first.
References
The following sources were accessed on August 29, 2026.
- FIRST: Exploit Prediction Scoring System
- FIRST: How EPSS Works
- FIRST: Using EPSS
- FIRST: EPSS Frequently Asked Questions
- FIRST: EPSS Research
- FIRST: Get the Data
- FIRST.Org REST API: GET /epss
- Empirical Security: Historical EPSS Scores
- Exploit Prediction Scoring System (2021)
- Enhancing Vulnerability Prioritization: Data-Driven Exploit Predictions with Community-Driven Insights (2023)
- CVE Program: Related Efforts
- CVE Program & FIRST VulnCon 2026
KestreLynx is open-source software that regularly scans images used by running Docker and Kubernetes containers with Trivy and sends changes since the last scan and priorities based on severity, CISA KEV, and EPSS to Slack or a webhook. For Docker and Compose, remediation plans and pull requests (experimental) support remediation from comparing update candidates to creating GitHub pull requests, with both features disabled by default. Users handle merging, rebuilding, and deployment.