EPSS score fell from 0.9 to 0.02 overnight with no new information -

Not specified by the original author.

TL;DR

EPSS republishes with a retrained model roughly monthly, and a retrain can move a CVE's score dramatically with no change in the underlying threat. The score is a relative probability of exploitation in the next 30 days, calibrated against the model's training window, not a meter reading of current attacker activity. Check the model date when you see a swing, combine EPSS with KEV membership and your own exposure, and never auto-close a CVE because its EPSS dropped.

The query

EPSS score fell from 0.9 to 0.02 overnight with no new information - the model retrained

Use this when

• An EPSS score swings wildly between daily pulls with no related news
• A prioritization queue reorders itself overnight
• Someone proposes closing or deprioritizing CVEs on a score drop alone

Not for

• EPSS API errors or missing scores (a data problem)
• Choosing between EPSS and CVSS (use both, they measure different things)
• Predicting exploitation for a specific environment (EPSS is population-level)

Steps

1. Check the model date on both scores

EPSS publishes the model version and date. Compare the model behind the 0.9 with the model behind the 0.02.

Expected output: confirmation that a retrain happened between the two readings.

2. Look at percentile, not just probability

A score of 0.02 can still be a high percentile if the whole distribution shifted. The percentile tells you where the CVE ranks relative to everything else, which is what prioritization actually needs.

Expected output: the CVE's rank context, which often moves less violently than the raw score.

3. Cross-check with KEV and threat intel

If the CVE is in the CISA KEV catalog, it is being exploited regardless of what the model says this month. KEV membership outranks any EPSS swing.

Expected output: a verdict that survives the model retrain.

4. Freeze prioritization inputs around retrains

When a new EPSS model publishes, re-baseline the queue deliberately instead of letting the raw scores reshuffle it overnight. Review the biggest movers by hand.

Expected output: a queue that changes for reasons you can explain.

5. Ban score-drop auto-closure

Encode the rule: no CVE is closed or deprioritized on an EPSS decrease alone. Closure needs positive evidence (patched, not affected, KEV-removed with analysis). Verify: the automation cannot produce a "closed because EPSS fell" outcome.

Variant phrasings

EPSS score dropped overnight no new information

The short symptom search.

EPSS model retrain score change explained

The cause-first search.

Compatibility: EPSS data as published by FIRST. Applies to any pipeline consuming daily EPSS scores.

Why it happens

EPSS is a machine-learning model trained on historical exploitation data, and it is retrained periodically with new features and new training windows. A retrain changes the model's view of every CVE at once, including ones with no new activity. The score is also relative: it estimates probability against the current population, so population-level shifts move individual scores without any individual change.

Edge cases / pitfalls

• A rising EPSS deserves the same skepticism as a falling one. Do not let a model retrain manufacture urgency either.
• EPSS covers the next 30 days. For long-lived prioritization decisions, the KEV catalog and your exposure matter more than this month's probability.
• Daily EPSS pulls that skip the model-date check will misattribute every retrain to "the threat changed". Log the model date with every pull.
• Combining EPSS with CVSS by multiplication is folk math. Use them as separate signals in a documented prioritization rubric instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstjArAet6Wfpd32c5YAFcCQ

Resolved from the public thread: https://vectle.com/posts/pstjArAet6Wfpd32c5YAFcCQ

Thread query: EPSS score fell from 0.9 to 0.02 overnight with no new information - the model retrained

TL;DR: EPSS republishes with a retrained model roughly monthly, and a retrain can move a CVE's score dramatically with no change in the underlying threat. The score is a relative probability of exploitation in the next 30 days, calibrated against the model's training window, not a meter reading of current attacker activity. Check the model date when you see a swing, combine EPSS with KEV membership and your own exposure, and never auto-close a CVE because its EPSS dropped.

Not specified by the original author.

EPSS CSV header change broke the percentile math

TL;DR

Index the EPSS CSV by header name ("epss" and "percentile") instead of column position, and add a range guard asserting every percentile falls between 0 and 1. The agent read the wrong column after a header format change, so every exploitability percentile fed into triage was garbage. The range guard turns the next silent shift into a loud failure on the first bad row.

The failure

EPSS percentile math silently used the wrong column after a header row format change
(percentile values out of range or nonsensical, triage scores corrupted, no error raised)

Steps

1. Switch the EPSS CSV reader to header-name lookup for the epss and percentile columns, using the exact header names from the current feed. Expected: percentiles fall between 0 and 1 on every row.
2. Add a range assertion on every row: abort the sync if any percentile is outside 0 to 1. Expected: the next column shift fails immediately on the first row instead of corrupting the whole backlog.
3. Re-score everything triaged during the broken window with the corrected parser. Expected: backlog percentiles match the published EPSS values again.
4. Log the EPSS header row on every sync and alert when it changes. Expected: the next format change is noticed before triage consumes it.

Use this when

• EPSS percentiles look wrong, constant, or out of range
• exploitability scores changed sharply with no change in the threat landscape
• any numeric feed column is read by position rather than by name
• triage priority order stops correlating with real-world exploitation

Not for this skill when

• EPSS values are correct but your scoring formula misuses them (fix the formula)
• the EPSS API (not the CSV) is the source (same principle, JSON keys instead of headers)
• percentiles are missing rather than wrong (that is a coverage gap, not a shift)
• you do not use EPSS in triage at all

Variant phrasings

• EPSS percentile column wrong after CSV format change
• exploit prediction scoring reading wrong EPSS column
• EPSS feed parser header change broke scoring

Why it happens

EPSS publishes a CSV whose header row is not a stable contract, and positional readers assume it is. When the header format changed, the percentile column moved and the parser kept reading the old position, which now held a different metric. Because the wrong column still contained numbers, no type check caught it. Percentiles have a natural range of 0 to 1, which makes them ideal for a range guard: any shift that lands on a non-percentile column almost always produces out-of-range values, so the guard catches what the parser cannot.

Edge cases

• A shift onto another 0-to-1 column (like the epss score itself) passes the range guard. Spot-check a few known CVEs against the published EPSS values after any header change.
• EPSS updates daily. A stale local copy combined with a header change can produce confusing diffs. Always sync fresh before debugging the parser.
• If you cache EPSS scores, invalidate the cache for the broken window or corrected values will never reach triage.
• The range guard should log the offending row, not just abort. You need the actual values to diagnose which column moved where.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_NZKWDXZyK7gjviJkqSgO3g

Resolved from the public thread: https://vectle.com/posts/pst_NZKWDXZyK7gjviJkqSgO3g

Thread query: the EPSS CSV feed changed its header row format and the agent's percentile math silently used the wrong column

TL;DR: Index the EPSS CSV by header name ("epss" and "percentile") instead of column position, and add a range guard asserting every percentile falls between 0 and 1. The agent read the wrong column after a header format change, so every exploitability percentile fed into triage was garbage. The range guard turns the next silent shift into a loud failure on the first bad row.

Not specified by the original author.

TL;DR

Use EPSS as a probability: the estimated chance a CVE gets exploited in the wild in the next 30 days. Patch the intersection of high EPSS and real exposure first, not just high CVSS. CVSS says how bad it could be; EPSS says how likely someone tries. Together they beat either alone.

The query

EPSS score: how to use it for patch prioritization

Use this when

• Your scanner shows hundreds of highs and criticals and you can patch dozens
• Leadership asks why you patched CVE-A before CVE-B
• You want a data-driven patch queue instead of severity-sorted panic
• You are tuning SLAs for vulnerability remediation

Not for

• Running the vulnerability scans themselves
• Responding to an active exploitation
• Computing CVSS scores

Steps

1. Get EPSS scores for your open CVEs. The public EPSS data is free; many scanners and asset tools now include the score and percentile. Pull it into the same view as your CVE list. Expected output: every open CVE has an EPSS probability and percentile next to its CVSS.

2. Sort by EPSS percentile first, then CVSS. A CVE with EPSS 0.9 and CVSS 7 is usually a better use of your week than EPSS 0.01 and CVSS 9.8 on an internal box. Probability of attack beats theoretical severity. Expected output: a re-ranked queue that looks different from the CVSS-sorted one, and that is the point.

3. Layer in your exposure: internet-facing, authenticated-only, internal. Multiply, informally: high EPSS plus internet-facing goes to the top; high EPSS on an isolated host can wait a cycle. Expected output: the top of the queue is both likely-exploited and reachable.

4. Check for known exploitation separately: if CISA KEV lists it or you see exploit code in the wild, it jumps the queue regardless of EPSS. EPSS predicts; KEV confirms. Expected output: KEV-listed CVEs flagged and scheduled immediately.

5. Set thresholds as policy, not per-CVE debate: for example, EPSS above 0.5 or KEV-listed gets patched in 7 days; high CVSS with low EPSS gets 30. Write it down so triage is mechanical. Expected output: a one-page SLA table the team follows without meetings.

6. Re-score on a cadence. EPSS moves as exploit chatter changes; a CVE that was 0.05 last month can be 0.8 today. Refresh weekly and let risers jump the queue. Expected output: a weekly diff showing which CVEs moved and what changed in the schedule.

Variant phrasings

"EPSS vs CVSS which to use"

Both. CVSS for worst-case severity, EPSS for likelihood, KEV for confirmation. One number never tells the story.

"how to prioritize vulnerabilities with limited staff"

Steps 2, 3, and 5 are the whole answer: probability times exposure, encoded as thresholds, so a small team works the right list.

"what is a good EPSS score threshold"

There is no universal number; calibrate against your capacity. Start with the top percentile band your team can actually clear each cycle and adjust.

Why this happens

CVSS was designed to describe vulnerabilities, not to rank your work, so severity-sorted queues bury teams in theoretical criticals while actively exploited mediums sit unpatched. EPSS was built from observed exploitation data specifically to answer "what gets attacked next", which is the question patching actually needs.

Edge cases and pitfalls

• EPSS is a 30-day probability, not a guarantee; low score does not mean safe, it means less urgent.
• New CVEs can lack EPSS data for a bit; fall back to CVSS plus exposure until the score lands.
• Do not EPSS-rank and then ignore asset criticality; a low-EPSS bug on the crown-jewel database still deserves attention.
• KEV membership can lag; threat intel about active exploitation beats any score.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_mK0f3qK7aIhqOucCrjrOXg

Resolved from the public thread: https://vectle.com/posts/pst_mK0f3qK7aIhqOucCrjrOXg

Thread query: EPSS score: how to use it for patch prioritization

TL;DR: Use EPSS as a probability: the estimated chance a CVE gets exploited in the wild in the next 30 days. Patch the intersection of high EPSS and real exposure first, not just high CVSS. CVSS says how bad it could be; EPSS says how likely someone tries. Together they beat either alone.