EPSS vs KEV: When Exploit Prediction and Active Exploitation Disagree

TL;DR

EPSS (Exploit Prediction Scoring System) predicts how likely a CVE is to be exploited in the next 30 days based on historical patterns. CISA’s KEV catalog lists vulnerabilities already being exploited in the wild. In theory, they should agree. In practice, KEV entries frequently sit at the bottom of the EPSS distribution — <1% probability, below the 5th percentile of all CVEs. EPSS is a model trained on yesterday’s data. KEV is today’s ground truth. When they disagree, KEV wins for prioritization.

What EPSS actually measures

EPSS estimates the probability of exploitation within 30 days using a logistic regression model trained on:

• CVE metadata (CVSS score, attack vector, complexity, etc.)
• Vendor and product attributes
• Time since publication
• Historical exploitation signals (exploit-in-availability, exploit-db presence, Metasploit modules)

The output is a single number between 0 and 1 — the estimated probability. It’s also percentile-ranked against all other scored CVEs.

EPSS is not a severity score. It doesn’t measure impact. A CVSS 10.0 vulnerability that affects a niche product with a small install base can have an EPSS of 0.001. A CVSS 5.4 in Apache Log4j has an EPSS of 0.975. EPSS measures likelihood, not damage.

The KEV-EPSS gap

Look at recent CISA KEV additions:

The Linux kernel entries are the most striking: CVSS 8.8, confirmed actively exploited (KEV), EPSS below 0.15%. The JFrog entries are similar — CVSS 8.1–8.8, KEV’d, EPSS <0.3%.

Even the highest-EPSS KEV entry in this batch (NetScaler at ~4%) is barely in double digits as a percentile.

Why EPSS misses these

EPSS is a predictive model. It learns from historical exploitation patterns — which CVEs got exploited first, which products saw faster adoption of exploits, which vulnerability classes are more “exploitable.” But it has blind spots:

1. New exploit patterns. If a vulnerability class is newly being exploited (e.g., ebtables OOB write in kernel networking), EPSS has no historical data for that specific attack vector. The model underestimates.

2. Low-install-base targets. CVEs in Linux kernel subsystems affect millions of hosts, but the attacked subset is narrow — anyone running ebtables with SNAT rules on a bridge. EPSS’s install-base signal may not capture this precision.

3. Time lag. EPSS is updated weekly. A CVE added to KEV on Monday may not appear in Wednesday’s EPSS update with the new exploitation data factored in. The model needs multiple data points before its probability shifts upward.

4. CVSS-driven bias. EPSS’s logistic model weights CVSS heavily. A CVSS 8.8 CVE starts with a higher prior probability than a CVSS 5.4 CVE — but within the same CVSS band, EPSS varies by two orders of magnitude. The model’s CVSS weighting means it treats all high-CVSS CVEs as equally likely to be exploited before looking at the finer attributes.

5. Zero-day supply chains. EPSS tracks public exploitation signals (Exploit-DB, Metasploit, commercial exploit vendors). If a vulnerability is exploited via a custom module before it appears in a public database, EPSS won’t know until the exploit is catalogued — which often lags KEV by days or weeks.

What KEV captures that EPSS doesn’t

CISA’s KEV catalog has different selection criteria:

• Evidence of exploitation in the wild (not just in the lab)
• Clear mitigation guidance
• Impact on public sector or broad industry (not just niche products)

KEV is not a probability. It’s a binary state: exploited or not. And “exploited” means CISA observed it affecting at least one organization — usually multiple — during a specific window. The KEV signal is stronger than EPSS for current triage because it answers “is this being used right now?” rather than “is this likely to be used soon?”

The KEV catalog also has a due date — a deadline for remediation. Federal agencies get 3–28 days depending on risk. This deadline is a pressure signal: the shorter the deadline, the more aggressively the exploit is spreading.

The triage matrix

The intersection of EPSS and KEV produces four quadrants:

The interesting zone is low EPSS + in KEV — the gap where the model underestimates but the ground truth says otherwise. Every KEV entry in this zone is a correction signal for the model and a prioritization signal for operators.

The other useful zone is high EPSS + not in KEV — vulnerabilities likely to be exploited before they’re catalogued. These are the ones you patch proactively because EPSS is telling you the exploit is coming.

How to use both without double-counting

The most common mistake is treating EPSS and KEV as additive signals — “this CVE has high EPSS and is in KEV, so it’s 2x important.” They’re not independent. A KEV entry’s high EPSS in later updates is caused by the KEV data feeding back into the model. Double-counting inflates the priority.

The working pattern:

1. KEV is the primary filter. Any CVE in KEV that matches your assets gets patched before non-KEV items, regardless of EPSS. The deadline is the SLA.

2. EPSS is the secondary filter. Among non-KEV items, EPSS tells you which to patch first. High EPSS without KEV status means “exploit is likely but not yet confirmed in the wild” — patch ahead of low-EPSS items.

3. KEV-EPSS gap is the warning. Items with low EPSS but KEV status are model blind spots. Track them separately. When the next EPSS update shows their score jumping, you’ve confirmed the gap. When it doesn’t jump after 2–3 updates, the exploit may be narrow (few affected hosts) or the exploitation signal hasn’t propagated to EPSS’s training data yet.

Real-world example: the Linux kernel pattern

The Linux kernel entries from this week (CVE-2026-53266, CVE-2025-39964) demonstrate the pattern clearly:

• Both are CVSS 8.8 — high severity
• Both are in KEV with 3-day deadlines
• Both are below 1.5% EPSS
• Both affect the kernel — an “always-on” component with broad exposure

EPSS’s kernel prior is high (kernel CVEs get exploited more often than average), but the specific subsystems (ebtables SNAT, a race condition in kernel crypto) are narrow enough that EPSS’s exploitability estimate stays low. CISA’s KEV decision is based on observed exploitation — and kernel memory corruption in networking is a ransomware operator’s bread and butter.

For operators running Linux servers (which is most of them), both entries are in the “fix within 72 hours” zone regardless of what EPSS says. The kernel patch is a standard apt upgrade or yum update. The cost is negligible. The risk of waiting for EPSS to catch up is a weekend of exploitation.

What happens to EPSS over time

EPSS is updated weekly. Once a CVE enters KEV, its EPSS score typically rises within 1–3 updates as the exploitation data propagates through the model. But the rise is not guaranteed — if the exploit only affects a narrow subset of the product’s install base, EPSS may stay in the single digits even years after KEV entry. This is not a model failure; it’s a model reflecting a narrow exploit.

The practical takeaway: don’t wait for EPSS to rise after KEV entry. The KEV deadline is already set. If EPSS is still low two weeks after KEV entry, the exploit is probably targeting a specific configuration or subsystem — worth noting, but not a reason to deprioritize.

The bigger lesson

EPSS and KEV answer different questions:

• EPSS: “How likely is this CVE to be exploited in the next 30 days?”
• KEV: “Is this CVE being exploited right now?”

EPSS is useful for planning — which non-KEV items to patch first when you have a backlog. KEV is useful for triage — which items to patch immediately because they’re in the wild. They complement each other. They don’t duplicate each other. And when they disagree, the disagreement is where the interesting work happens.

The organizations that patch by CVSS alone are missing both dimensions — they don’t know which high-CVSS CVEs are actually being exploited and which mid-CVSS CVEs have high exploitation probability. Adding EPSS fixes the probability blind spot. Adding KEV fixes the exploitation-status blind spot. Using both, and respecting when they disagree, produces a triage that’s actually useful.

Further Reading

• First.org EPSS — exploit prediction methodology and scoring
• CISA Known Exploited Vulnerabilities catalog — the ground truth of active exploitation
• CISA KEV Criteria — what goes into KEV and what doesn’t
• BOD 26-04 — federal vulnerability prioritization guidance built on KEV
• EPSS Model Documentation — how the logistic regression model works and what data it uses