Home / Knowledge hub / Exploitability
Knowledge hub
Exploitability
How easily and reliably a flaw can be used in practice.
What it means
Exploitability is a measure of how easy it is to turn a flaw into something an attacker can use. It depends on how the flaw is reached, what the attacker needs first, how many tries it takes and whether a working method is already known. Some flaws need one request. Others need rare conditions.
It is separate from impact. Impact says what the attacker gains. Exploitability says how hard it is to gain it. CVSS scores the two together, which is why a flaw that is easy to use but only reads a harmless page can rate lower than a harder one that exposes everything.
Why it matters
Two flaws with the same score can deserve very different treatment. One needs an attacker already on your internal network with a specific account. The other can be used by anyone, from the internet, with a single request. The second gets fixed first, even if the numbers match.
Exploitability in theory and in your system are not the same. A vendor rating assumes a typical setup. Your firewall, your configuration and your login rules may make the flaw much harder, or easier, to use. Only testing against the running application settles it, as in a proof of concept.
How it shows up
Look for it in the access-related metrics of a CVSS vector: how the flaw is reached, how complex it is, what privileges and user action it needs. Public exploit code, a Metasploit module or a listing in the CISA known exploited list all raise it sharply.
The usual mistake is accepting a rating without checking the conditions behind it. A flaw rated hard because it needs a login may be trivial if signing up is free. Another rated easy may be blocked by a control the rating never knew about. Test the claim in your own setup.
Questions people ask
Exploitability, answered
Is exploitability the same as severity?
No. Severity combines how easy a flaw is to use with how much damage follows. Exploitability is only the first half.
A flaw can be very easy to use and low in severity, or hard to use and high in severity.
What makes a flaw easy to exploit?
Reachable from the internet, no sign-in needed, no user action, low complexity and public exploit code all make it easier.
Reliability matters too. A method that works every time is worth more to an attacker than one that works one time in fifty.
How do I know if a flaw is exploitable in my app?
Try it, carefully and with permission, against a running copy. Reading a description tells you what could happen. Running the steps tells you what does.
A penetration test that exploits the finding provides this evidence.
Does public exploit code mean it is easy to exploit?
It makes it easier, because the hard work is done. It does not guarantee success against your version or configuration.
Treat it as a strong warning and check your own exposure promptly.
Can exploitability change over time?
Yes. New tools, published techniques and automation make once-hard flaws easy.
A rating from a year ago may no longer fit, so revisit older findings when new evidence appears. Check a few times a year whether old, accepted findings have become easier.
Sources
Where this comes from
Related
Terms that sit next to this one
Exploit maturity
How developed and available attack code is for a given flaw.
Exploit
The specific sequence that turns a suspected weakness into a real one.
CVSS vector
The short string that records each factor behind a CVSS score.
EPSS
A score estimating how likely a vulnerability is to be exploited in the next thirty days.
Proof of exploit
Evidence that a flaw can be used to cause real impact, not just that it exists.
Easy on paper, easy in your app?
We exploit a finding to confirm it, so exploitability in your app comes with a request, a response and a screenshot where a person can see it. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.