Wiki · Concept · Last reviewed June 25, 2026

Exploit Prediction Scoring System

The Exploit Prediction Scoring System, usually shortened to EPSS, is a FIRST project that estimates how likely a published CVE is to see observed exploitation activity in the wild during the next 30 days. It is an exploit-likelihood signal, not a severity score, local risk score, or proof of compromise.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: AI security, vulnerability management, EPSS, CVSS, exploit prediction, governance

Definition

The Exploit Prediction Scoring System (EPSS) is a FIRST Special Interest Group project for estimating exploit likelihood for vulnerabilities identified by CVE. FIRST describes EPSS as a data-driven machine-learning model that estimates the probability that a published CVE will be exploited in the wild in the next 30 days. Its scope is the CVE ecosystem; vulnerabilities or AI failure modes without CVE identifiers do not receive EPSS scores.

EPSS is not the same thing as CVSS, a proof of compromise, a vulnerability disclosure process, or a legal duty to patch. CVSS captures severity characteristics of a vulnerability. EPSS asks a narrower operational question: given current evidence and model features, how likely is this CVE to see observed exploitation soon? It does not answer whether the vulnerable component is deployed, reachable, business-critical, or exploitable in a particular local environment.

For AI and agent systems, EPSS matters because modern AI stacks still depend on ordinary software: browsers, containers, model-serving services, identity providers, package managers, vector databases, orchestration layers, and tool servers.

Snapshot

How It Works

FIRST publishes an EPSS score for every CVE on a daily basis. The current data feed includes a CVE identifier, an EPSS value, and a percentile. The EPSS value is a probability between 0 and 1. The percentile shows where that score sits relative to other scored vulnerabilities.

The distinction between probability and percentile is important. A probability is the model's estimate of observed exploitation in the next 30 days. A percentile is a rank position. A vulnerability can have a small absolute probability while still ranking high compared with the long tail of low-likelihood CVEs. FIRST's guidance recommends communicating the probability as the main EPSS score and adding the percentile when it helps explain relative priority.

The model process is empirical. FIRST's model page describes a cycle of collecting vulnerability information, collecting evidence of daily exploitation activity, training a model on the relationship between those inputs and observed exploitation, measuring performance, and refreshing estimates daily. It treats exploitation activity as observed attempted exploitation, not proof that an attacker successfully compromised a vulnerable target.

EPSS does not replace severity scoring. A low-severity vulnerability with a high EPSS score may need fast attention because exploitation is likely. A severe vulnerability with a low EPSS score may still matter because it affects a central identity service, public-facing model gateway, or regulated data system. The useful triage record keeps EPSS beside CVSS, asset exposure, business context, exploit evidence, VEX status, and compensating controls.

Current Context

As of June 25, 2026, FIRST's EPSS pages present EPSS as a daily, open data feed available through CSV and API. The data page lists the current fields as cve, epss, and percentile; the API page documents lookup by CVE, historical date, time series, score thresholds, percentile thresholds, and ordering.

Versioning matters. FIRST's data page says no EPSS scores are available before April 14, 2021; EPSS v2 began publishing on February 4, 2022; EPSS v3 began publishing on March 7, 2023; and EPSS v4, identified as v2025.03.14, began publishing on March 17, 2025. Historical analysis should preserve model version and date because score distributions can shift across model releases.

The wider vulnerability-management context is also moving toward dynamic risk signals. CISA's June 2026 Binding Operational Directive 26-04 is not an EPSS rule, and it applies to Federal Civilian Executive Branch agencies rather than the whole private sector. It still reflects the same governance direction: prioritization should use current evidence about exposure, exploitation, automation, and impact rather than static severity alone. The directive says urgency is determined by asset exposure, KEV status, exploit automation, and technical impact; its implementation guidance notes that CVSS labels such as critical or high do not prescribe specific actions by themselves. EPSS, KEV, SSVC, CVSS, VEX, and local asset context are complementary signals, not interchangeable labels.

Decision Use

EPSS is most useful when it is treated as one column in a decision table. A high EPSS score says exploitation is comparatively likely soon. It does not say the vulnerable component is deployed, exposed, reachable, or important. A low EPSS score says observed exploitation is less likely under the model, not that a vulnerability can be ignored in identity infrastructure, public services, safety-relevant systems, or regulated-data workflows.

A disciplined triage process separates five questions. Severity asks what exploitation could do, often using CVSS or vendor analysis. Threat likelihood asks whether exploitation is likely, where EPSS is useful. Known exploitation asks whether the CVE is already in CISA KEV or equivalent evidence sources. Applicability asks whether the vulnerable code is present and reachable, where VEX and testing help. Local consequence asks what happens in this deployment, including exposure, data sensitivity, agent authority, recovery time, and mission impact.

The safest display is a multi-column record rather than a single opaque number. Show EPSS probability and percentile beside severity, exposure, known-exploited status, VEX status, asset owner, compensating controls, and decision deadline. If a team uses a combined score, the formula and overrides should be documented so reviewers can see which signal moved the decision.

Teams can still define local bins such as urgent, high, watch, and accepted risk, but the bins should be published as local policy. FIRST's EPSS guidance explicitly warns that binning is a subjective transformation of a probability scale, so thresholds should be justified by capacity, exposure, service criticality, and the organization's risk appetite rather than presented as universal EPSS labels.

For auditability, every automated rule should be explainable. A rule such as "patch within 72 hours when EPSS is above a threshold and the asset is internet-facing" should record the threshold, score date, asset-exposure evidence, exception owner, rollback plan, and the reason the rule does or does not override vendor guidance, VEX status, or KEV deadlines.

Common Misreadings

High EPSS is not high impact. A high probability says exploitation is likely soon under the model. It does not say exploitation would be catastrophic, that the component is exposed, or that the affected code is reachable in this deployment.

Low EPSS is not safe. FIRST says EPSS is the threat component in a broader risk decision, and the score is never a complete risk score. A low-probability CVE can still require urgent work if it affects identity, production administration, safety-relevant systems, public services, regulated data, or a privileged agent action path.

Percentile is not probability. FIRST's probability-percentile guidance explains that percentiles are ranks across all scored vulnerabilities. A vulnerability can sit in a high percentile while its absolute probability is still modest, because most CVEs have very low observed exploitation rates.

Not in KEV is not "not exploited." CISA's Known Exploited Vulnerabilities Catalog is an authoritative known-exploited list with its own evidence criteria. Absence from KEV is not proof that exploitation is impossible, unobserved everywhere, or irrelevant to local risk.

No CVE means no EPSS score. Prompt injection, unsafe agent delegation, misconfiguration, leaked credentials, poisoned retrieval content, and weak tool authorization may be serious security issues without receiving EPSS scores unless they are represented as CVEs.

Calibration and Thresholds

FIRST's user guide says EPSS estimates the threat component in a risk-based vulnerability-management process and should never be treated as a risk score. That distinction should shape threshold design. A threshold is an operational policy that trades effort against coverage; it is not a property of the CVE itself.

Before automating deadlines from EPSS, teams should backtest candidate thresholds against their own inventory. FIRST's model guidance frames strategy performance in terms of effort, efficiency, and coverage: how many vulnerabilities the rule asks teams to work, how many prioritized items were later observed exploited, and how much observed exploitation the rule captured. Those metrics are more useful than a single "high EPSS" label because they reveal the cost of missed exploitation and wasted work.

Calibration should be repeated after score-distribution shifts, major model releases, asset-exposure changes, new KEV additions, and changes in staffing capacity. If an organization recalculates percentile ranks over its local vulnerability subset, the display should say so; FIRST's global percentile and a local percentile answer different ranking questions.

Agent Context

Agentic systems create vulnerability-management pressure because they connect many ordinary services into action paths. A coding agent may touch repositories, package registries, CI logs, credentials, and local filesystem state. A browser agent may sit on top of browser engines, authentication sessions, screenshot pipelines, and task queues. A customer-service agent may combine retrieval, email, CRM access, and escalation tools.

EPSS helps triage the ordinary CVEs inside those paths. It does not capture prompt injection, unsafe delegation, memory poisoning, model behavior failures, weak tool authorization, or agent-specific escalation unless those problems are represented as CVEs. For that reason, EPSS belongs beside agent-specific review methods such as OWASP AI Vulnerability Scoring System, AI Agent Identity, AI Agent Sandboxing, and AI Agent Observability.

The practical agent question is not "what is the EPSS score?" by itself. It is whether a vulnerable component is deployed in an action path, reachable by untrusted content, able to access credentials, attached to a tool or MCP server, or present in a production workflow where exploitation could change records, leak data, or gain execution.

Governance and Safety

A governance program can use EPSS as a dated triage signal. A good vulnerability record should preserve the CVE, EPSS probability, percentile, score date, source feed or API query, severity source, affected asset, exposure, connected agent or model service, business owner, decision, exception rationale, and reassessment date.

The date matters because EPSS is refreshed daily. A score copied into a ticket without a timestamp may keep influencing decisions after the threat landscape changes. A mature program should recalculate, close stale exceptions, and show score drift when an ignored vulnerability becomes more likely to be exploited.

The governance risk is score automation without accountability. EPSS can improve prioritization, but it should not silently patch, defer, or accept risk by itself. Human owners still need to decide what happens when exploit likelihood, user impact, legal sensitivity, uptime risk, and operational capacity point in different directions. Automated remediation is most defensible when the rule is documented, staged, monitored for false positives and false negatives, reversible where possible, and backed by AI Change Management and incident-response authority.

For AI systems, EPSS should connect to an AI System Inventory, AI Bill of Materials, Vulnerability Exploitability eXchange statements, AI Audit Trails, and AI Incident Reporting. A score is useful only when it can be mapped to the deployed component, owner, exposure path, mitigation, and evidence trail.

Minimum Triage Record

A useful EPSS-based decision leaves enough record for a later reviewer to reconstruct why a vulnerability was patched, mitigated, watched, or temporarily accepted.

Limits

EPSS is a threat-likelihood signal, not an asset-risk score. It does not know whether a given organization runs the affected product, whether the asset is internet-facing, whether vulnerable code is reachable, whether a patch is safe, or whether exploitation would affect a high-impact workflow.

EPSS also does not cover zero-days before CVE assignment, private vulnerabilities, misconfigurations without CVEs, compromised credentials, prompt injection, unsafe agent tools, poisoned retrieval data, model-weight theft, or many AI-specific vulnerabilities that live outside the CVE ecosystem.

Percentile values are especially easy to misuse. FIRST's guidance warns that percentiles are a relative rank across all scored vulnerabilities; they do not reconstruct the underlying probability and may be misleading when a team is only comparing a local subset of deployed vulnerabilities.

Defense Pattern

Source Discipline

Claims about EPSS should cite FIRST material directly. The most important source distinction is between the official EPSS definition, the daily data fields, the API, the model description, and explanatory guidance on probabilities and percentiles. Secondary dashboards can be useful for workflow, but they should not be treated as the source of the scoring method.

EPSS should also not be confused with AI Vulnerability Disclosure, CVE assignment, CVSS severity, CISA KEV, VEX, SBOMs, vendor advisories, proof of exploitation, or AI-specific scoring systems. Those artifacts can complement one another, but each answers a different governance question.

Claims about CISA policy should cite the exact CISA artifact. BOD 26-04 is a binding directive for Federal Civilian Executive Branch agencies; the KEV Catalog is CISA's authoritative list of vulnerabilities known to have been exploited in the wild; and CISA's SSVC materials describe a decision method with values such as exploitation status, technical impact, automatability, mission prevalence, and public well-being impact. None of those artifacts makes EPSS a compliance mandate.

When citing an EPSS score, preserve the CVE, score date, probability, percentile, model version where available, and source endpoint or CSV date. A screenshot or ticket field without the score date is weak evidence because EPSS changes daily and model versions can change distributions. Third-party dashboards may be convenient interfaces, but governance records should retain the FIRST feed or API evidence behind the displayed score.

Spiralist Reading

Spiralism reads EPSS as a probability layer placed over institutional urgency. Security teams already know that not every vulnerability can be fixed first. EPSS makes one part of that triage explicit: the expected nearness of exploitation.

The number is useful when it sharpens responsibility. It is dangerous when it hides responsibility behind a dashboard. The healthy ritual is a documented argument over likelihood, exposure, severity, dependency, and the human owner willing to accept delay.

Open Questions

Sources

Return to Wiki