EPSS vs. Exploitability: Why Probability ≠ Risk in Your Environment

Understanding EPSS: Global Patterns, Local Blindspots

The Exploit Prediction Scoring System (EPSS) is a data-driven model that predicts the likelihood a given software vulnerability will be exploited in the wild. In essence, EPSS crunches global vulnerability and attack data to output a probability (0 to 1) that a CVE will see exploitation activity on the internet at large (typically within the next 30 days). A high EPSS score means attackers somewhere are statistically more likely to target that CVE soon. However – and this is critical – EPSS is not a contextual risk rating for your specific organization. As the EPSS maintainers themselves caution, “EPSS is estimating the probability of exploitation activity, which is just one of many considerations in a risk-based approach… EPSS should never be treated as a risk score”. Other factors like how accessible a vulnerable system is, what weakness type it is, and an asset’s purpose and value in your environment all influence actual risk.

In simpler terms, EPSS is all signal, no situational awareness. It offers a bird’s-eye view of what attackers are generally doing, akin to a weather forecast for threats on the global internet. But just as a city’s average rainfall doesn’t tell you if your street will flood, an EPSS score doesn’t tell you the exploitability of a vulnerability in your network architecture, on your servers, under your security controls. It’s a powerful statistical tool – the first of its kind to quantify threat likelihood using real-world exploit data – yet it has a narrow scope: probability of any exploit attempt, anywhere. That is not the same as probability of compromise in your environment. This distinction is where many vulnerability management programs get tripped up.

The Misinterpretation: EPSS ≠ “Exploitability in My Environment”

Because EPSS provides a convenient numeric likelihood, there’s a temptation to treat it as an exploitability rating for local patch decisions. This is a dangerous oversimplification. Misinterpreting EPSS can lead teams to ignore vulnerabilities that appear low-risk by EPSS, only to discover (the hard way) that those bugs were linchpins in an attack path specific to their organization.

Why doesn’t a low EPSS guarantee safety? EPSS is a one-size-fits-all machine learning model trained on global data. It excels at finding general patterns – which CVEs are being exploited broadly by criminals, botnets, or script kiddies – but it is blind to local context. It doesn’t know if a vulnerable service in your network is exposed to the internet, or if that service sits on an internal admin subnet behind multiple layers of defense. It doesn’t know if the vulnerable software is mission-critical to your operations or just running on a test box. It can’t see your configuration, compensating controls, user privilege model, or crown jewel assets. In short, EPSS knows nothing about you.

Imagine a CVE that requires a very specific configuration or user interaction to exploit – such vulnerabilities often get low EPSS scores because opportunistic attackers won’t mass-scan for them. But if you happen to have that exact configuration, or an insider can perform that user interaction, the vulnerability might be trivially exploitable in your environment. EPSS would misleadingly suggest “low chance of exploit,” because on a global scale it’s rare, yet for you it could be a ticking time bomb. As the EPSS user guide emphasizes, EPSS only relates to the threat component of risk, not the impact or your particular exposure. A low EPSS simply means fewer observed attacks across the whole internet, not that your organization specifically is invulnerable to it.

Real-world data underscores this gap. A Qualys analysis found that only ~2% of vulnerabilities receive High/Critical EPSS scores, while “almost everything else is rated as Low” – even cases where there is clear evidence of active exploitation in the wild. In other words, EPSS classifies the vast majority of CVEs as low probability, yet we know many “low EPSS” vulns do get exploited (sometimes in targeted ways). Why? Often because those exploits aren’t widespread enough to move the global needle. Additionally, EPSS scores can drop once a patch is available (attackers may pivot away to easier targets), but that doesn’t magically patch your systems – if you haven’t applied the fix, the risk remains even if EPSS says “low”. Relying purely on EPSS could lull you into a false sense of security for a vuln that threat actors assume you haven’t patched yet.

Case Study: When Low EPSS Meets High Stakes (CVE-2024-34341)

To illustrate, let’s examine a recent highly visible application-layer bug: CVE-2024-34341. This CVE affects the Trix rich text editor (used in web frameworks like Next.js) and was disclosed in May 2024. It’s essentially a client-side XSS (cross-site scripting) flaw – when a user pastes specially crafted content, the editor fails to sanitize it, allowing malicious scripts to execute. In other words, an attacker can smuggle a script into the application by tricking someone into pasting malicious HTML/JS (for example, via a copied snippet from a webpage). Trix versions <2.1.1 were vulnerable, and while a patch was quickly released, many apps using Trix had to scramble to update.

On the surface, CVE-2024-34341 didn’t set off alarm bells globally. Its CVSS base score was 5.4 (Medium), reflecting that it’s network exploitable (AV:N) and requires no privileges, but does need user interaction (UI:R) and “only” impacts confidentiality/integrity of the app (not a full system compromise in itself). The EPSS score hovered around 0.2 (20% probability) – not particularly high. In fact, an EPSS of 0.2 put this vulnerability roughly in the 39th percentile by risk (well below the top criticals). Many organizations might see that and conclude, “Meh, odds are low that anyone will exploit this. We have bigger fish to fry.” After all, it’s “just an XSS,” and requires a user to paste something – not the kind of thing botnets aggressively seek out.

However, context is everything. Consider a company that built an internal CMS or customer portal on Next.js, which uses the vulnerable Trix editor component. In that specific environment, this “medium” XSS could be a critical issue. For instance, suppose the portal is used by administrators or privileged users – if an attacker phishes one admin into pasting a malicious payload (perhaps disguised as formatting instructions), the script could silently execute in their browser session. That might allow the attacker to perform privileged actions or steal sensitive data via the admin’s credentials. In a worst-case scenario, the XSS could be a stepping stone to full account takeover or lateral movement (imagine the script creating a new admin user or dropping a web shell via an admin function).

None of these nuances were captured by the EPSS score. EPSS saw a mid-score CVE that wasn’t being mass-exploited on day one. But in an enterprise that relied heavily on this component, CVE-2024-34341 proved extremely risky. In fact, had that organization waited for EPSS to spike or for it to land on a “Known Exploited Vulnerability” list, they might have been too late. This example drives home a key point: a vulnerability with low EPSS can still be the pivot an attacker uses in a targeted breach, especially if your architecture makes it attractive. EPSS told us the probability someone on the internet would weaponize Trix XSS was low; it did not tell us the probability our Trix-using app would be targeted or the impact if it was. The latter requires understanding our app’s role, data, user privileges, and exposure.

We see similar patterns frequently. Vulnerabilities in niche or internally-deployed software often have low EPSS simply because they’re not widespread enough to generate attack chatter. Yet if you use that niche software in a critical workflow, a determined adversary (say, a state-sponsored group or a financially motivated insider) will gladly exploit it regardless of EPSS. The threat isn’t coming from opportunistic mass-scanners; it’s coming from targeted attackers who research your tech stack. In such cases, treating EPSS as a go/no-go for patching is courting disaster.

Why EPSS is Like an ImageNet Classifier (Analogy)

To really grok the limitation, it helps to use a machine learning analogy (in true Andrej Karpathy fashion). Think of EPSS as an ImageNet-trained classifier in the vulnerability space. ImageNet models are excellent at recognizing broad classes of objects in photos – cats vs. dogs, cars vs. planes – because they’ve seen millions of examples and learned the general patterns. Likewise, EPSS has been trained on millions of data points about vulnerabilities and exploits, learning patterns like “RCEs in popular products tend to get exploited” or “if a metasploit module is out, expect more attacks.”

But what happens when you ask a generic image classifier a very context-specific question? For example: “Is this blurry shape in my backyard camera feed a threat to my property?” The model might confidently say, “That’s just a cat” based on global patterns – when in fact it’s a mountain lion specific to your region. The classifier lacks local context: it doesn’t know your neighborhood, the difference between your pet cat vs. a wild cougar, or that you care specifically about threats to your yard. Similarly, EPSS is blind to context cues that determine exploitability in your environment. It doesn’t know which servers are in your DMZ versus behind a VPN, which apps have admin users with access to crown jewels, or how a seemingly minor bug could be chained with another misconfiguration to escalate privileges.

In ML terms, EPSS optimizes for overall accuracy across a broad dataset, not for your particular data distribution. It’s a global model that treats every vulnerability as if it lives in an abstract, average network. This yields a kind of “one-size-fits-most” prediction. But your network is not the average network! There’s a classic precision vs. recall trade-off here too: EPSS is tuned to catch the big fish (common exploits) with few false positives, which means it will inevitably miss or underweight some fish that are rare globally but highly relevant locally (false negatives for you). In short, EPSS is like a talented but context-oblivious AI: great at spotting trends, terrible at understanding importance in any given scenario.

Karpathy often talks about layering – how complex behaviors emerge from simple layers learning features. We can imagine EPSS’s “layers” as learning features like CVSS scores, exploit code availability, age of CVE, etc., up to a final layer outputting a probability. It might even internally have a “concept” for likely exploited vs unlikely exploited. But what EPSS doesn’t have is a layer that inputs “value of target” or “exposure in ACME Corp’s network” – those features aren’t in the model. They can’t be, because EPSS doesn’t tailor itself to each organization. If we wanted an analogy to that, we’d be talking about fine-tuning a model on your own data – which is exactly what a savvy security team must mentally do on top of EPSS outputs.

So, treat EPSS like an ImageNet classifier: a powerful general detector that provides useful baseline predictions, but requires additional local tuning and filters to get the full picture. Just as a self-driving car’s vision system needs maps and context to know a stop sign from a poster of a stop sign, your vuln prioritization needs context to know a low-EPSS flaw from a low-risk flaw.

The Risk of One-Size-Fits-All Patching

When vulnerability management teams conflate “low EPSS” with “not worth patching here”, they risk creating blind spots in their defenses. A common scenario is patch deferral based on EPSS: e.g. an org might delay patching a moderate CVE because EPSS is 0.1 (10% chance). If this decision is made without further analysis, the team is implicitly assuming their environment conditions match the internet average conditions used by EPSS. Often, that assumption is wrong.

For instance, consider a vulnerability in an obscure enterprise application with a complex exploit method. EPSS might stay low because few attackers bother with it globally. Now imagine your organization is one of the few using that app, and it’s internet-facing due to business needs. From an attacker’s perspective, you have a rare but juicy target. If they specifically want to breach your company, they’ll exploit that obscure vuln if it’s the easiest pathway – global odds be damned. By misreading EPSS as an absolute measure of exploitability, you’d underestimate a serious threat. This is how we see breaches where the entry point was an “unimportant” CVE that the victim left unpatched while chasing higher-EPSS issues that, ironically, might not have even existed in their network.

Another issue is timing and threat actor behavior. EPSS is reactive to observed exploits; a sophisticated adversary might deliberately use a novel or lightly-exploited vulnerability precisely because it flies under the radar. They know defenders are watching the high-EPSS, heavily reported bugs. So they’ll look for something with a lower profile that still gets the job done – maybe a chain of a low-EPSS vulnerability with a configuration mistake, or a medium-severity bug in a third-party component (sound familiar? like our Trix editor example). If your patch prioritization logic is “EPSS above X% = immediate, below = later,” you’ve just handed the attacker a menu of less-watched options.

All of this circles back to the core point: EPSS does not measure “risk to my organization”; it measures “likelihood some actor somewhere will exploit this CVE.” Treating those as equivalent will skew your priorities. As FIRST.org’s EPSS guidance puts it, “asset owners should consider many other aspects… before making a final decision to remediate or delay remediation”. EPSS is one lens (the threat lens) – without the other lenses of exposure, impact, and asset value, you’re essentially trying to judge a painting wearing one blurry contact lens.

A Layered Approach: Integrating EPSS with Environmental Context

How can vulnerability management teams harness EPSS effectively without falling into the trap of one-size-fits-all? The answer lies in combining EPSS with rich context from your own environment. Think of it as blending the generalized intelligence of EPSS with the specific knowledge of your assets, architecture, and threats – the result is a far more precise prioritization model. Here are some strategies and data points to integrate alongside EPSS when building your patch prioritization logic:

• Asset Visibility & Criticality: Maintain an up-to-date inventory of your IT assets and assign a criticality level to each (consider using an asset management or Exposure Management tool). Which systems are mission-critical? Which house sensitive data? If a vulnerability (even low EPSS) affects a critical asset or a key business application, bump up its priority – the impact of compromise is higher for you. Conversely, a high-EPSS vuln on a lab system with no sensitive data might not outrank a medium-EPSS vuln on a production database. Knowing what truly matters to the business is step one.
  
  
• Software Bill of Materials (SBOM): Use SBOMs to understand which third-party libraries and components are in your applications. EPSS might not scream about a vulnerability in a less common library, but if that library is part of your tech stack, it’s your concern. For example, if you had an SBOM for your Next.js app, it would flag the inclusion of the vulnerable Trix editor, letting you know CVE-2024-34341 is relevant. Tie your SBOM data to vulnerability feeds so you catch transitive risks. This helps you not overlook “low-profile” CVEs that are quietly embedded in your software.
  
  
• Attack Surface Management (ASM): Identify which vulnerable systems are exposed to potential attackers. Is a given CVE present on an internet-facing server, on a system in a DMZ, or deep in your internal network? An internet-facing or otherwise accessible vulnerability should be prioritized because attackers (even unskilled ones) can reach it easily. EPSS doesn’t know if your vulnerable service is behind seven proxies or open to the world – but you do. Incorporate reachability: e.g., tag vulnerabilities in externally facing apps higher. Many teams now tag assets as “internet-facing” in their vuln management platforms for this reason.
  
  
• Endpoint & Network Telemetry (EDR/NDR): Leverage your security monitoring. If your EDR or IDS/IPS is detecting exploit attempts (or even suspicious probing) for a certain CVE in your environment, treat that as a flashing red light. This is direct evidence of interest in that vulnerability against you, which trumps any statistical score. For instance, if you suddenly see scanning or weird input patterns hitting a web app endpoint corresponding to a low-EPSS CVE, you should re-prioritize that patch immediately. Your telemetry can also reveal if a vulnerability has already been exploited (e.g., a webshell dropped) – obviously at that point, EPSS is irrelevant and incident response and patching are urgent.
  
  
• Threat Intelligence & KEV Lists: Keep an eye on threat intel feeds and the CISA Known Exploited Vulnerabilities list. If a vulnerability is known to be exploited in the wild (even by a single APT group), that’s a strong signal it could be used in a targeted attack against you, regardless of EPSS percentage. In fact, EPSS might lag behind emerging exploits – especially if they aren’t yet widespread. Treat intel reports of exploitation as an override to EPSS: a CVE with EPSS 0.1% but mentioned in a threat report targeting your industry should move up your queue. Many orgs combine EPSS with an “exploited Y/N” flag (from CISA KEV or other sources) to refine prioritization.
  
  
• Threat Modeling & Chaining Scenarios: Go beyond one-vuln-at-a-time thinking. Use threat modeling to ask, “What could an attacker do in my environment if they exploited this vulnerability?” Maybe by itself a flaw just leaks info (low impact), but could that info enable a bigger attack? Or perhaps a low-EPSS remote code execution on a non-critical server could serve as a foothold that an attacker uses to pivot into your crown jewels. Model adversary behavior (assume breach mentality) and see where each vuln sits in an attack path. This helps identify seemingly minor issues that are actually key links in a kill chain. Prioritize vulnerabilities that are attack enablers in your specific context. This is analogous to how a defensive driver is always thinking “What could that other car do that would be bad for me?” rather than just trusting the low likelihood of any given car swerving.
  
  
• Combine Scores into a Custom Risk Formula: Ultimately, consider constructing your own risk scoring that multiplies or weighs EPSS by local factors. For example, some organizations create a composite score: Risk = EPSS_probability * Asset_Criticality * Exposure_Factor * Impact_Severity. If a vuln is on an internet-facing, critical asset, that Exposure and Criticality multiplier shoots up, even if EPSS is small. Conversely, a high EPSS on a non-critical isolated system might get dampened by those factors. This way, you’re effectively customizing the EPSS model to your environment. Security vendors are heading this direction too – for instance, Qualys’ “TruRisk” and others merge EPSS with business context to produce a tailored risk score. Whether you use a commercial tool or home-grown formula, the goal is the same: augment EPSS with your data to predict your likelihood of exploit and impact.
  
  

By integrating these layers, you transform patch prioritization from a blunt, globally-informed list to a nuanced, context-aware decision process. You get the benefits of EPSS’s big-data-driven foresight and you avoid its blindspots by filling in the local details. The result is a much smarter vulnerability management program that can answer the real question: “What should we patch first, given our unique risk landscape?”

Conclusion: Global Predictions Need Local Knowledge

EPSS has been a game-changer for vulnerability management, bringing an empirical, attacker-informed perspective that CVSS alone never provided. It’s like having an expert guide who tells you, “Out of 180,000 CVEs, here are the few hundred that bad actors are most likely to go after in the next month”. But remember: that guide is speaking in generalities, not about your network specifically. EPSS offers probability, not prophecy. A low EPSS score does not mean “safe for me,” and a high score doesn’t automatically mean “critical for me” – you have to map that information onto your environment.

In the style of Karpathy’s thoughtful analyses, we can appreciate the elegant trade-off EPSS makes: it simplifies the exploit likelihood question by stripping away all context (because it has to apply to everyone) and focusing purely on global threat dynamics. This simplicity is both its strength and its weakness. The strength is a clear signal amid the noise of tens of thousands of CVEs. The weakness is the absence of personalization – something no single global model can provide. To manage vulnerabilities effectively, you need to provide that personalization yourself, via asset context, threat modeling, and all the strategies discussed. It’s the classic “human in the loop” approach: an automated system (EPSS) surfaces patterns, and human analysts (or custom tooling) adjust for what the system doesn’t know about the local reality.

In closing, vulnerability management teams should leverage EPSS as a powerful tool – but not a crutch. Use it to inform and enrich your decision-making, not to replace it. Treat EPSS like an expert consultant whose advice must be interpreted in light of your own domain knowledge. By doing so, you avoid the pitfalls of misinterpreting probability as impact. The internet at large is not your network, and exploitability “in the wild” is not the same as exploitability in your data center. The organizations that grasp this will patch smarter and faster where it truly counts. Those that don’t may end up chasing ghosts in the machine, while the real threat walks in through an unlocked side door marked “low EPSS.”

Stay layered, stay contextual, and happy patching. 

References:

• FIRST.org – Exploit Prediction Scoring System (EPSS) Overview & User Guide
  
  
• Wiz.io – CVE-2024-34341 Analysis (Trix Editor XSS in Next.js)
  
  
• Qualys Blog – “How EPSS and Context Improve Patch Prioritization”
  
  
• Microsoft Security – Defender Vulnerability Management Adds Asset Context & EPSS (example of combining internet-facing asset tags with EPSS)
  
  
• Additional CVE details from NVD, CISA KEV, etc., as cited in-line above.

‍