The EPSS daily file changed models on June 15, 2026. The first line of the June 14 file reads #model_version:v2025.03.14 (v4). The June 15 file reads #model_version:v2026.06.15 (v5). We compared those two files, which together hold 340,204 CVEs scored on both days. If your pipeline gates on a fixed EPSS probability, it lost about a quarter of its flagged CVEs overnight: 23,069 CVEs scored 0.1 or higher under v4 and 17,041 under v5. Nothing about those vulnerabilities changed that day; the model did.

This article covers what changed in v5, what the shift looks like in the data, and what to re-baseline. For the file format itself (columns, header line, how to join it to a scanner export), see our EPSS data feed guide. That guide already lists the five model versions and their start dates; this one measures the most recent change.

What changed in v5

Empirical Security, which runs the EPSS model and hosts the data, announced EPSS V5 on May 13, 2026. The release says v5 “incorporates improved modeling techniques and optimization algorithms” and that “the calibration step has been refined.” It also cites a better classifier for published exploit code and “the addition of new data feeds.”

The headline claim is a 23% improvement. Empirical’s research post defines the metric only loosely, as one that rewards “ranking genuinely exploited vulnerabilities above ones that pose no real threat.” On data from May 4, 2026, it reports that v4 scored 0.514 and v5 scored 0.633, where “a random guess would score around 0.025, and a perfect model would score 1.0.” We did not reproduce that evaluation.

The rollout is visible in the public empiricalsec/epss_scores repository:

The beta files carry a different model label (v2026.05.12) from the production model, so treat beta scores as a preview of v5, not as v5 itself. The repository README lists the model changes for v2, v3 and v4 but, as of November 6, 2026, has no v5 entry. The file header was the reliable signal.

The CSV format did not change. Both files have the same comment line followed by cve,epss,percentile.

How the scores moved

We loaded 2026/epss_scores-2026-06-14.csv.gz and 2026/epss_scores-2026-06-15.csv.gz from the repository and compared CVEs present in both. For a baseline, we ran the same comparison on June 13 and June 14, two consecutive v4 days.

Three patterns stand out.

The distribution got narrower. The lowest v4 score was 0.00001 and 93,484 CVEs sat below 0.001. Under v5 the minimum is 0.00046 and only 3,552 CVEs are below 0.001. At the top end, the 99th percentile fell from 0.772 to 0.595. The median ratio of v5 to v4 score was 2.89: most low-scored CVEs went up, while many of the high scorers came down. That fits the release’s description of recalibration, but the release does not say this is the intended effect, so treat it as our reading of the data.

Fixed cutoffs shrank. A rule like epss >= 0.1 matched 26.1% fewer CVEs the day v5 went live, and epss >= 0.5 matched 40.9% fewer. Of the CVEs that crossed 0.1, 9,847 dropped below it and only 3,820 rose above it.

Percentile rules kept their size, not their members. A percentile is a rank, so the 90th-percentile bucket stays about 10% of scored CVEs. But 9,837 CVEs entered it and 9,944 left it in one day, compared with 25 and 29 on a normal v4 day. If you track “new CVEs in the top decile” as a work queue, June 15 would have looked like a flood.

1,146 CVEs scored on June 14 were missing from the June 15 file and 43 appeared for the first time. By November 5, all but 119 of the missing ones were back in the feed. We did not establish why they were absent that day.

What happened to KEV-listed CVEs

To see whether v5 demoted known-exploited vulnerabilities, we took the CISA KEV catalog (catalog version 2026.11.04) and kept only the 1,619 entries whose dateAdded is on or before June 14, 2026, so the set matches what was known on the switch date. All 1,619 were scored on both days.

The probability for KEV entries came down along with the rest of the high end. But almost the same number cleared 0.1, and more of them landed in the top decile. KEV-listed CVEs that a 0.1 rule already caught were still caught. A rule set to 0.5 or 0.7 on the assumption that KEV CVEs sit there would have lost many of them, since the median is now about 0.54.

This is one reason KEV should stay a separate input instead of being folded into an EPSS cutoff. Our CVSS vs EPSS vs KEV comparison covers why; the prioritization workflow shows where each signal sits in the patch decision.

What to re-baseline

These are our recommendations, based on the data above. We have not measured their effect on any team’s backlog.

1. Find every fixed probability cutoff. SLA rules, ticket triggers, dashboard colours and scanner policies. If one was tuned against v4 data, check how many CVEs it matches today versus before June 15.
2. Decide what the cutoff is for. If it sizes a queue (“the top few thousand CVEs”), switch it to a percentile. If it expresses risk (“at least a 10% chance of exploitation in 30 days”), keep the probability, because v5’s calibration is meant to make that reading more accurate, but accept that the queue size will move.
3. Do not compare scores across the switch. A CVE that went from 0.4 to 0.2 on June 15 did not become less likely to be exploited that day. If you chart EPSS history, mark June 15, 2026 (and the earlier switches on 2022-02-04, 2023-03-07 and 2025-03-17).
4. Keep KEV as an override. Do not rely on EPSS to bring KEV entries above a high cutoff.
5. Store model_version next to every score. Then you can always tell which model produced a score your system acted on.

A guard for the next model change

There is no API callback when the model changes, but the file tells you. This script compares the header of yesterday’s and today’s file and exits non-zero on a model change, so a CI job or cron wrapper can stop before ingesting.

"""Stop an EPSS ingest when the model version changes.
Usage: python3 epss_model_guard.py yesterday.csv.gz today.csv.gz"""
import gzip, sys

def header(path):
    with gzip.open(path, "rt") as f:
        first = f.readline().strip()
    if not first.startswith("#"):
        return {"model_version": "pre-v2 (no header)", "score_date": ""}
    return dict(kv.split(":", 1) for kv in first.lstrip("#").split(","))

old, new = header(sys.argv[1]), header(sys.argv[2])
print(f"previous: {old['model_version']} scored {old['score_date']}")
print(f"current:  {new['model_version']} scored {new['score_date']}")
if old["model_version"] != new["model_version"]:
    print("MODEL CHANGE: hold threshold-based alerts and re-baseline before ingesting")
    sys.exit(2)

We ran it with Python 3 against files from the repository:

$ python3 epss_model_guard.py epss_scores-2026-06-14.csv.gz epss_scores-2026-06-15.csv.gz
previous: v2025.03.14 scored 2026-06-14T12:55:00Z
current:  v2026.06.15 scored 2026-06-15T12:03:41Z
MODEL CHANGE: hold threshold-based alerts and re-baseline before ingesting
exit=2

$ python3 epss_model_guard.py epss_scores-2026-11-04.csv.gz epss_scores-2026-11-05.csv.gz
previous: v2026.06.15 scored 2026-11-04T12:03:12Z
current:  v2026.06.15 scored 2026-11-05T12:03:04Z
exit=0

When the guard trips, run the same comparison we did above (counts at your cutoffs, percentile churn, KEV coverage) before you turn alerts back on. Note the score_date format also changed with v4 (from +0000 offsets to Z), so parse it as ISO 8601 instead of matching a fixed string.

Limits of this article

• We compared one pair of days. Scores on later v5 days have kept moving as new signals arrive, so today’s counts differ from June 15.
• The 23% improvement figure and the description of model changes come from Empirical Security. We did not test model accuracy.
• KEV is a list of vulnerabilities known to be exploited, not a ground truth for EPSS’s 30-day prediction window, so the KEV table shows coverage, not accuracy.
• We did not find a FIRST page describing v5 in the sources we could reach. If FIRST publishes a different start date or model description, the file headers above are still what your pipeline will see.

Sources and verification