Definition
Exploitability is how easily an attacker can actually use a vulnerability against a real system. It depends on whether the system is reachable, how complex the attack is, whether an exploit exists and which defences are in place.
What exploitability means
Exploitability describes how easily an attacker can actually use a vulnerability against a real system. A vulnerability is a weakness; exploitability is whether, and how easily, that weakness can be turned into an attack.
Two vulnerabilities with the same severity score can be very different in practice. One might be reachable from the internet with a public exploit that anyone can run. The other might need local access, a specific configuration and a logged-in user who clicks something. The first is highly exploitable; the second may never be used at all.
Exploitability vs severity vs risk
These terms are often used as if they mean the same thing:
| Term | Question it answers | Example |
|---|---|---|
| Severity | How bad would it be if this was exploited? | A remote code execution flaw is rated critical |
| Exploitability | How easily can an attacker actually use it? | A working exploit exists and the system is exposed |
| Risk | How likely is it to hurt us, and how badly? | Exploitable flaw on a server that holds customer data |
Severity describes the vulnerability in general. Exploitability and risk depend on your environment: where the system sits, what protects it and what it gives access to.
What makes a vulnerability exploitable
- Reachability: can an attacker reach the vulnerable system or code at all, for example from the internet or from inside the network?
- Attack complexity: does it work reliably, or does it need special conditions, timing or configuration?
- Privileges required: does the attacker need an account first, and with what rights?
- User interaction: does someone have to click a link or open a file?
- Exploit availability: is there public exploit code, a tool or a module that automates it?
- Active exploitation: are attackers already using it in the wild?
- Compensating controls: do firewalls, segmentation, MFA or other defences block the attack?
How exploitability is measured
CVSS exploitability metrics
The Common Vulnerability Scoring System includes exploitability metrics in its base score: Attack Vector, Attack Complexity, Privileges Required and User Interaction (with Attack Requirements added in CVSS v4.0). They describe how hard a vulnerability is to exploit in general, but not whether it can be exploited in your environment.
EPSS
The Exploit Prediction Scoring System, maintained by FIRST, estimates the probability that a vulnerability will be exploited in the wild in the next 30 days. It is based on real-world data and is updated daily, which makes it useful for deciding what to patch first.
Known exploited vulnerabilities
The CISA Known Exploited Vulnerabilities (KEV) catalog lists vulnerabilities that attackers are confirmed to be using. If a vulnerability is on the list and present in your environment, it should be near the top of the queue.
Proven exploitability
Scores and predictions are estimates. The only way to know whether a vulnerability is exploitable in your environment is to try it safely, the way a penetration test does. A confirmed exploit removes the guesswork: it shows that the attack works, what it gives the attacker and what they could reach next.
Why exploitability matters for prioritisation
Most organisations have far more vulnerabilities than they can fix at once, and only a small share of known vulnerabilities are ever exploited. Prioritising by severity alone leads to:
- Wasted effort on critical-rated issues that cannot be reached or used
- Missed risk from medium-rated issues that are easy to exploit or sit on an attack path to something valuable
- Long backlogs that never get smaller
Prioritising by exploitability, and by what an exploit would give the attacker, focuses the team on the issues that actually matter.
How to assess exploitability
- Map what is exposed so you know which systems an attacker can reach.
- Check threat intelligence: EPSS scores, the KEV catalog and public exploit availability.
- Consider your controls: segmentation, MFA and other defences that may block the attack.
- Look at the impact: what the vulnerable system holds and what it gives access to.
- Validate it: confirm exploitability with a penetration test instead of relying on scores alone.
- Re-test after fixing to prove the vulnerability can no longer be used.
How Plainsea helps
Plainsea focuses on proven exploitability. Within the scope you set, AI agents try to exploit each potential weakness the way a real attacker would, and only findings that are confirmed exploitable reach your team, with the evidence to show it. Because weaknesses are chained into attack paths, you also see what each exploit leads to, and you can re-test fixes on demand.