Vulnerability Exploitability: Is That Critical CVE Reachable?

We recently got a call to the WTF Hotline.

A 9.8 CVE turned into a canceled release, a canceled anniversary dinner, and a caller who wasn’t speaking to his team lead anymore. All to fix a vulnerability that nobody could have ever actually reached.

That happens more than most teams want to admit. So here’s the question worth actually answering: how do you actually assess vulnerability exploitability in your own environment, before you burn a week finding out the hard way?

This Isn’t a One-Off Problem, It’s a Pattern

That caller isn’t an outlier. Ask almost any security team how they decide what gets fixed first, and the honest answer is usually: whatever has the highest score. A 9.8 comes in, and the response is automatic – escalate, staff it, treat it like the building’s on fire. Nobody checks whether the building even has that room in it.

That’s the gap at the heart of vulnerability severity vs risk, and it shows up in backlog after backlog. Severity tells you how bad a vulnerability could be in theory. It says nothing about whether an attacker could ever actually reach it in your environment. Treat the two as the same thing, and a 9.8 sitting in dead code will keep outranking a live, reachable 6.

So before anyone pulls engineers off a release next time, ask the question nobody asked on that call: is this vulnerability actually exploitable in your environment, right now?

Why This Keeps Happening: Vulnerability Severity vs Risk

There are different approaches to vulnerability prioritization, with one of the most widely used methods being the Common Vulnerability Scoring System (CVSS). Let’s start with what CVSS actually is. CVSS rates a vulnerability from 0 to 10 based on things like attack vector, complexity, and privileges required, plus what happens if it’s exploited. It’s a severity rubric, a way to describe how bad a flaw could theoretically be, on a scale everyone can point to.

The people who built it have said outright that it was never meant to drive prioritization on its own. FIRST’s own guidance says as much. It became the default anyway, mostly because for a long time it was the only shared language security teams had.

The problem is the scale doesn’t actually help you decide anything. Somewhere between 50 and 60% of all published CVEs land in “High” or “Critical.” When most of your backlog is rated critical, “critical” stops meaning anything.

It also doesn’t move. A score gets assigned once, shortly after a CVE is published, and almost never gets revisited — whether that vulnerability later gets weaponized in the wild or never gets touched by an attacker at all. None of that – the score, the scale, the age of it – tells you whether the vulnerable code is even reachable in your own systems. That was never a question CVSS was built to answer.

EPSS Helps, But It Still Can’t See Your Environment

EPSS is a real step up. Built by the same organization behind CVSS, it’s a machine learning model that estimates the probability a given vulnerability will actually be exploited in the wild in the near future. Instead of guessing at theoretical severity, it’s trained on real exploitation data, such as threat intel feeds, honeypots, and public exploit code, and it updates as new evidence comes in.

That’s a genuine improvement over scoring severity alone. Instead of treating every “critical” the same, EPSS gives you a sense of which vulnerabilities attackers are actually going after right now, versus which ones are just sitting there with a scary label attached.

But EPSS has the same blind spot as CVSS, just dressed up better. It’s still a global, aggregate score; it tells you whether someone, somewhere, is likely to exploit this vulnerability. It says nothing about whether that vulnerability is reachable in your specific build. It has no idea if the vulnerable function is ever called, if a firewall rule or network segmentation is already blocking the path, or if the code even loads at runtime.

Stack CVSS and EPSS together and you get a sharper read on severity and likelihood – but the vulnerability severity vs risk gap is still wide open. You still can’t determine whether this vulnerability can touch your systems specifically. Both signals can agree something is dangerous and still be wrong about whether it can reach you at all.

The Missing Layer: Is It Actually Exploitable In Your Environment?

This is the question CVSS and EPSS were never built to answer, and it’s the one that actually determines vulnerability exploitability for your specific systems. Answering it is what reachability analysis does: tracing whether the vulnerable code is actually loaded and called at runtime, mapping how exposed it is on the network, and checking whether anything already sitting in front of it – a firewall rule, a WAF, an access control – would stop an attacker from ever getting there.

In the WTF Hotline call above, you can see exactly what “unreachable” looks like in practice. A component that’s internal-only. Layers of network segmentation between it and anything an attacker could touch. Code that isn’t even loaded at runtime. Any one of those conditions can turn a 9.8 into a non-event. All of them together, and there was never a path to exploit it in the first place.

That’s the part severity scores can’t capture: the same CVE can be genuinely critical in one environment and completely irrelevant in another. Severity doesn’t change. Exposure does. It depends entirely on how a specific system is built, deployed, and locked down.

So instead of asking how high the score is, ask this instead, for every finding that lands in front of you:

• Is the vulnerable code actually present in production, not just sitting in a test or dev environment?
• Is it invoked or loaded at runtime, or is it dead code nobody calls?
• Is it network-reachable, or exposed on any path an attacker could realistically take?
• Are there compensating controls – segmentation, firewall rules, access restrictions – already standing in the way?
• Is there any confirmed evidence of real-world exploitation for this specific CVE, in an environment like yours?

How To Actually Fix Triage: Risk-Based Vulnerability Management

Turning that checklist into a program means changing how triage actually works, not bolting one more check onto the pile. This is what risk-based vulnerability management means in practice; not a philosophy, but a specific set of decisions about what triggers escalation. Severity tells you how bad something could be, likelihood tells you how attractive a target it is, and reachability tells you whether either of those matters in your environment. 

Exploitability validation

Confirm whether the vulnerability could actually function on that specific asset, not just in theory. Check the runtime configuration against what an attacker would actually need in place to weaponize it, using real exploit intelligence, not assumptions. A critical flaw that requires conditions your systems don’t have isn’t exploitable, whatever the score says.

Reachability analysis

Confirm whether anything could actually get to it in the first place. For code, that means checking whether the vulnerable function is ever invoked given how the application is built. For a dependency, whether the vulnerable function is actually imported and called, not just listed in a manifest. For infrastructure, whether the asset is exposed at all, based on things like security groups, public IP presence, and active connection patterns.

Risk-tiered SLAs

Tier your response times by this evidence. A finding that’s confirmed exploitable and exposed earns a tight SLA. Something theoretical or unreachable goes on a standard cycle. Not every 9-or-above CVSS score deserves the same clock, and pretending otherwise is how teams end up fixing the wrong things first.

Evidence trail

Attach the evidence to the finding, and make it specific. Every “not exploitable” verdict should carry its own reasoning inside the ticket or system of record – what was checked, what was found. That’s the difference between a verdict someone can trust and a checkbox someone has to take on faith.

Continuous re-verification

Re-check instead of setting and forgetting. A vulnerability that’s unreachable today doesn’t stay that way forever. A new deployment, a decommissioned firewall rule, a network change — any of it can turn “safe” into “exploitable” overnight. Verdicts need a refresh cadence, not a one-time stamp.

AI-driven exposure investigation

None of this holds up if it depends on a person doing it by hand. Manually investigating one finding this way is realistic; doing it across a backlog of tens of thousands isn’t, no matter how good a security team is. That’s the gap AI-driven exposure investigation closes; running the exploitability and reachability checks automatically, at the point of triage, so a verdict and its evidence are already attached to a finding before it ever reaches an engineer’s desk. The attacks racing toward your systems are increasingly AI-generated. Keeping pace with them takes a  response that moves just as fast.

Stop Scoring, Start Validating

None of this gets fixed with a better score. CVSS tells you how bad something could be; EPSS tells you how likely it is to be exploited somewhere in the world. Neither one knows anything about your systems specifically. The only way to actually answer the question of vulnerability exploitability in your environment is to check it directly, and to build that check into triage itself through AI-driven exploitability validation and reachability analysis. That’s what risk-based vulnerability management looks like when it’s actually operational; decisions driven by reachability, not raw scores.

Seemplicity’s AI Analysts run the exploitability and reachability checks automatically, so a finding arrives already confirmed instead of just scored.

The next 9.8 that lands in your queue might be real. The only way to know for certain is to validate active risk exposure, before anyone cancels their evening to fix something that was never actually a threat.