Why can EPSS stay low when attackers already have a working exploit?

Why EPSS can stay low even when exploit code exists

EPSS is a probability model, so it can remain low even after exploit code appears if the broader signal set still suggests limited expected exploitation. A working exploit does not automatically mean broad adoption, repeatable success, or enough observed activity for the model to move quickly. That is why teams should pair EPSS with exploit evidence and exposure context rather than treat it as a binary “safe or unsafe” flag.

Two things matter here: EPSS is trained from observed exploitation patterns, and exploit code can exist before those patterns become visible at scale. A newly published or niche exploit may be technically real but still uncommon, hard to weaponise reliably, or mostly discussed in places that do not strongly influence the model. If you want a deeper explanation of how EPSS fits into broader prioritisation, the FIRST EPSS reference is the best starting point.

The operational implication is that a low EPSS score should never override stronger indicators such as active probing, exposed services, proof-of-concept code, or confirmed exploitation in the wild. In practice, the score is telling you that the model has not yet seen enough evidence to infer likely near-term abuse, not that the flaw is theoretical. When exploit availability and EPSS disagree, exposure and adversary behaviour should drive the next decision.

What the model sees, and what it can miss

EPSS is useful precisely because it tries to estimate near-term exploitation probability, not merely vulnerability severity. That means it weights observable signals like prevalence, exploitation patterns, and historical behaviour, which helps explain why a live exploit can coexist with a low score if the exploit is not yet showing up in the model’s signal environment. The result is a timing gap between exploit availability and exploitation probability.

This gap is most visible when the exploit is new, narrowly targeted, or hard to operationalise. A proof-of-concept might be public, but if it is unreliable, requires unusual conditions, or has not yet circulated widely, the model may still stay conservative. For teams tracking vulnerable products, the NIST National Vulnerability Database remains the canonical place to confirm the vulnerability record, while EPSS adds a separate exploitation-likelihood layer rather than replacing that record.

That distinction matters because prioritisation breaks when teams confuse “exploit exists” with “exploit is likely at scale.” The first is a factual condition; the second is a forecasting problem. EPSS can understate urgency in the short term when the exploit is fresh, specialised, or not yet widely observed, so exposure context has to fill the gap.

How to interpret a low EPSS score in practice

Use EPSS as one input to prioritisation, not as the final decision. If the asset is exposed to the internet, the vulnerable service is reachable, or there is evidence of scanning or exploitation attempts, the practical risk is higher than the score alone suggests. That is especially true when the flaw is already being discussed in threat reporting or appears in active exploitation tracking such as the CISA Known Exploited Vulnerabilities Catalog.

Teams should also treat a low EPSS score as a reason to verify, not a reason to dismiss. Check whether the exploit is genuinely working in your version and configuration, whether the service is exposed externally, and whether compensating controls reduce the real attack surface. If the answer is yes to any of those, the issue deserves action even if the model remains cautious.

Risk and Threat Considerations

A low EPSS score can create a false sense of safety when attackers already have a working exploit. The risk is not that the model is wrong in a mathematical sense, but that it may lag behind a fast-moving exploitation cycle, especially when activity is still emerging or concentrated in a narrow victim set.

Failure mechanism: The model only updates when exploitation signals become visible enough to influence its forecast, so a real exploit may exist before the data shows broad abuse.

Impact: Teams may defer remediation, leaving exposed systems available for opportunistic use, follow-on probing, or the first wave of mass exploitation.

Practitioner Guidance

What to prioritise: Treat exploit availability, exposure, and observed probing as higher-priority signals than EPSS alone when the two disagree. If the service is internet-facing or the exploit is reproducible, move from score-based triage to exposure-based triage.

What to verify: Confirm whether the exploit works against your exact configuration, whether the vulnerable path is reachable, and whether there are signs of scanning, failed logins, abnormal requests, or post-exploitation behaviour. Those checks tell you more about immediate risk than the score does.

Practitioner takeaway: EPSS is a forecast, not a verdict, so a low score should slow down panic but never cancel evidence that the exploit is real and reachable.

Related resources from NHI Mgmt Group

• Why do Linux kernel bugs become a higher risk once attackers already have low-privilege code execution on the host?
• Why do airport websites stay vulnerable even when attackers use low-sophistication DDoS methods?
• Why do attackers still exploit email when web traffic is already protected by PKI and TLS?
• Why do denied prompts matter when attackers already have valid credentials?