A vulnerability is exploitable when an attacker can actually use it against you: it's reachable from where they stand, your version and configuration allow it, and it leads somewhere that matters. Most findings fail at least one of those tests. Google saw only 0.23% of the vulnerabilities disclosed in 2026 exploited. Exploitability finds the few that matter to you.
- Vulnerable describes the software. Exploitable describes your situation: reachability, version, configuration, and what the bug leads to.
- The volume is exploding and the exploited share is tiny. Monthly disclosures doubled in 2026, from 5,045 in January to 10,740 in August, per Google. Only 0.23% were seen exploited.
- The few that matter don't wait. In our analysis of CISA's catalog, half of the 2026 CVEs confirmed as exploited were confirmed within 4 days of publication.
- CVSS, EPSS and KEV each answer a different question. None of them knows whether your instance is reachable.
What does "exploitable" mean?
In everyday English, exploitable means something can be used to someone's advantage. In security, it means an attacker can use a weakness to do something they shouldn't, in a specific environment, from a position they can actually reach.
NIST defines a vulnerability as a weakness in a system, its procedures, controls or implementation "that could be exploited" by a threat source. The word doing the work there is could. A vulnerability is a possibility. Exploitability is the test of whether that possibility is real for you, today.
A vulnerability is exploitable only when three things hold at once:
- It's reachable. The attacker can get to the vulnerable code from where they are. For almost every attacker, that's the internet.
- It's possible here. Your version, configuration, authentication and controls let the exploit work.
- It leads somewhere. Success gets the attacker something worth having: data, credentials, code execution, or the next step in a chain.
If one fails, you still have a real vulnerability that deserves a fix in its turn. It just shouldn't set this week's priorities. And all three can change overnight: a new subdomain, a changed setting, a public exploit.
What's the difference between a vulnerable and an exploitable vulnerability?
Vulnerable describes your software. Exploitable describes your situation. A scanner can tell you that a host runs a version with a known CVE. It can't tell you whether anyone outside can reach that code, whether your configuration blocks the exploit, or what an attacker gets if it works.
| Vulnerable | Exploitable | |
|---|---|---|
| Question it answers | Does a known weakness exist here? | Can an attacker use it against us, now? |
| Evidence | A version match or a scanner signature | A reproduced attack path |
| Unit | A finding (a CVE, a misconfiguration) | A path from entry point to impact |
| Typical volume | Thousands | A handful |
| Who sorts it | Your team, by hand | Whoever validated it, before it reaches you |
| What it creates | Work | A decision |
The last row is the one I care about. A list of 4,000 findings is exposure. Three validated attack paths that end at customer data is exploitability. The first creates work. The second creates a decision.
Why aren't 4,000 findings 4,000 risks?
Because almost none of them will ever be used against you, and the list doesn't tell you which ones will.
I've sat with security teams carrying around 4,000 open findings from one tool and 5,000 from another, with almost nothing getting closed. Everyone reports, nobody remediates. Not from laziness: nobody can answer the first question R&D asks, which one first and why?
The global numbers explain why the list keeps growing. Google Threat Intelligence Group counted 5,045 vulnerabilities disclosed in January 2026 and 10,740 in August. The number exploited per month rose too, from an average of 10.5 in 2025 to 18. But as a share, it's tiny: only 0.23% of all vulnerabilities disclosed in 2026 were seen exploited.
The small share moves fast, though. In our analysis of CISA's Known Exploited Vulnerabilities catalog, the median 2026 CVE was confirmed exploited 4 days after publication, and 27% were confirmed the same day or earlier. VulnCheck found that 23.43% of the vulnerabilities with first-time exploitation evidence in the first half of 2026 were exploited on or before the day their CVE was published. And Mandiant's M-Trends 2026 found that exploits were the most common way attackers got in for the sixth year running, at 32% of intrusions.
So two things are true at once. Most of your list doesn't matter, and the part that does doesn't wait. A list sorted by severity hides both.
Doesn't CVSS already tell me what's risky?
No. CVSS measures severity, and its own authors tell you to add your context. FIRST describes CVSS as a framework for "communicating the characteristics and severity of software vulnerabilities." In version 4.0, the Base score is calculated with default values "that assume the highest severity" for the threat and environmental metrics. FIRST tells consumers to enrich it with values "specific to their use of the vulnerable system." Most teams never do. So the 9.8 on your dashboard is the worst case for everyone, not a statement about you.
Other signals help. Each one answers a different question:
| Signal | The question it answers | What it can't tell you |
|---|---|---|
| CVSS (FIRST) | How bad is it if someone exploits it? | Whether anyone can reach it in your environment |
| EPSS (FIRST) | How likely is exploitation in the wild in the next 30 days? | Whether your instance is the exposed one |
| CISA KEV | Is someone exploiting it right now? | Whether you're exposed, or how long you have |
| SSVC (CISA) | Should we Track, Attend or Act? | Nothing until you supply your own exposure and impact |
| Validated attack path | Can an attacker do this to us, from the internet, today? | Tomorrow's answer. It has to be repeated |
SSVC is closest to the right idea, because it's a decision tree, not a score. CISA's version weighs exploitation status, technical impact, automatability, mission prevalence and public well-being, and outputs one of four decisions: Track, Track*, Attend or Act. CISA's directive for federal agencies, BOD 26-04 (June 2026), is titled "Prioritizing Security Updates Based on Risk," and asset exposure is one of its four factors. The inputs most teams can't fill in honestly are the local ones: is it exposed, and is it exploitable here?
How do you know if a vulnerability is exploitable in your environment?
Ask three questions, in order, and accept only evidence as an answer. These are the questions we ask about every critical CVE, for every client:
- Is it actually exposed? Not what the CMDB says. What actually answers from the internet under your name, including a subdomain that points at a vendor's SaaS nobody remembers setting up.
- Is it exploited in the wild? Check KEV, vendor advisories and threat intelligence. "CVSS 10" isn't an answer. And "not yet" isn't permanent: the critical Metabase vulnerability CVE-2026-72898 (CVSS 10.0) was attacked on August 3, 2026, three days before the advisory and patches came out on August 6.
- Is exploitation possible here? Version, configuration, authentication, reachability. Prove it with a safe reproduction instead of inferring it from a version banner.
Then one more: if it works, where does it lead? A medium that hands over credentials outranks a critical that leads nowhere. Attackers chain. Your prioritization should too.
The target I give security teams: answer all three within 24 hours of a critical CVE. A week is too late.
What does the gap look like in a real engagement?
Usually like this: the scariest score on the report isn't the path a stranger can walk. Two examples from our work, with names removed.
The 9.9 and the setting
On the external attack surface of a digital-twin platform, our agents found 27 issues across two hosts: 4 critical, 8 high, 10 medium and 5 low. The highest score belonged to an end-of-life Jenkins server affected by CVE-2026-33001, a CVSS 9.9 arbitrary file write that leads to full controller compromise. Serious, and it needed fixing. But it requires an authenticated user with permission to configure jobs.
The path a stranger could walk was somewhere else: a public Grafana instance with anonymous access turned on. No CVE involved, just a setting in the config file. Anyone on the internet got the "Viewer" role, and that role could read the datasource configuration, which included the production database's host, name and user, and could send arbitrary SQL through Grafana's query proxy. We confirmed that the proxy forwarded our queries to the database. They returned no rows for one reason only: the database hostname wasn't resolving in DNS at that moment. Not authentication. Not authorization. The database happened to be offline.
| Finding | On paper | What the attacker needs | Usable by a stranger? |
|---|---|---|---|
| End-of-life Jenkins, CVE-2026-33001 | CVSS 9.9 | A logged-in user who can configure jobs | No |
| Grafana anonymous access + query proxy | No CVE, a config setting | Nothing. Only the database being online | Yes, the moment the database resolves |
Cylent engagement, 2026. Client and infrastructure details removed.
Turning off anonymous access closed seven of the 27 findings in one change. That's what a decision looks like.
The account that was a sign-up form away
At a smart-traffic company, the scope was one asset: a public CVAT annotation server, 39 releases behind the current version, with more than 11 published advisories against it. On paper, the comfort was that you needed an account to do anything.
But the server allowed open self-registration with no email verification. One request, and the anonymous attacker became an authenticated user. That turned every vulnerability that required authentication into one that didn't. A directory traversal (CVE-2025-68430) and a broken access control bug, where an empty request body returned other projects' data, gave us the metadata of all 35 projects, a map of the container's filesystem, and the company's proprietary object-detection models. We stopped there on purpose, before reading any secrets or attempting code execution.
Grafana and CVAT have a million eyes on their code. Nobody was looking at how these two instances faced the internet.
That's where exploitability lives.
How do you prioritize vulnerabilities by exploitability?
Start from what an attacker can reach, filter by what's exploited and possible in your setup, prove the path, then fix the pattern rather than the finding. That's risk-based vulnerability management taken literally. Better scores help, but a score is still a prediction. A validated path is evidence.
- Inventory from the outside in. Start with what answers from the internet, not with what's in the asset register. (How this differs from attack surface management.)
- Overlay exploitation signals. KEV first, then EPSS for what's likely next.
- Check the conditions locally. Version, configuration, authentication, and any control that actually sits in the path.
- Validate the path, safely, with a human signing off. AI agents make it cheap to investigate every candidate path. An experienced operator decides which ones are real before they reach your team. (What AI pentesting finds, and what still needs an operator.)
- Fix the root, not the row. One Grafana setting closed seven findings. In a mobile banking engagement, one inconsistent ownership check sat behind 22 vulnerable endpoints, and one fix pattern closed them all.
- Measure closure, not coverage. "We scanned 100% of assets" says nothing about risk. "We validated and closed every exploitable path we found" does.
What should you do this week?
- Take your top 20 open critical findings and, for each one, write down three answers: reachable from the internet, exploited in the wild, possible in our configuration. Count how many you can answer with evidence.
- Build your internet-facing inventory from DNS and certificate transparency, then compare it with the CMDB. The differences are where attackers start.
- Check every internet-facing tool for anonymous access and open sign-up: Grafana, Metabase, Jenkins, annotation tools, admin panels.
- Match your findings against the KEV catalog, and treat a KEV entry on an exposed asset as an incident, not a ticket.
- Look for the one setting or pattern behind each cluster of findings, and fix that.
- Change one line in your monthly report: replace "% of assets scanned" with "% of exploitable paths validated and closed."
- Drill the 24-hour question. A critical CVE drops. How long until you know whether you're exposed and whether it's exploitable in your setup? (What continuous external testing looks like.)
FAQ
What does exploitable mean in cybersecurity?
It means an attacker can actually use a weakness against a specific system: they can reach it, the system's version and configuration allow the exploit, and success gives them something of value. A vulnerability that exists but can't be reached or triggered in your environment is vulnerable, not exploitable.
What is exploitability?
Exploitability is how feasible it is for an attacker to use a vulnerability in practice. It depends on reachability, configuration, authentication requirements, the availability of exploit code, and whether exploitation is already happening in the wild.
Is every vulnerability exploitable?
No. Google Threat Intelligence Group found that only 0.23% of vulnerabilities disclosed in 2026 were seen exploited. Many more are exploitable in some environments and not in others, which is why the answer has to be checked per environment.
What's the difference between CVSS and EPSS?
CVSS, maintained by FIRST, scores how severe a vulnerability is if exploited. EPSS, also from FIRST, estimates the probability that a published CVE will be exploited in the wild in the next 30 days. Neither tells you whether your own instance is reachable.
What is risk-based vulnerability management?
Risk-based vulnerability management (RBVM) prioritizes vulnerabilities by the risk they pose to a specific organization, rather than by severity alone. It combines exposure, exploitation signals such as KEV and EPSS, and business impact. The strongest input is a validated attack path, because it replaces a prediction with evidence.
The bottom line
Vulnerable is a fact about software. Exploitable is a fact about you, and it changes every time your attack surface does. A list of 4,000 findings tells you how much work exists. Three validated paths tell you what to do on Monday. Exposure creates work. Exploitability creates a decision.
So here's my question: take the ten findings at the top of your dashboard right now. For how many could you prove, with evidence, that an attacker on the internet can use them against you today?
Sources
- NIST CSRC, Glossary: vulnerability (FIPS 200, from CNSSI 4009)
- Google Threat Intelligence Group, Vulnerability Discovery and Exploitation Trends in the AI Era (September 30, 2026)
- Cylent, Time to exploit in 2026 (analysis of CISA KEV catalog version 2026.10.30)
- CISA, Known Exploited Vulnerabilities Catalog
- VulnCheck, State of Exploitation 1H-2026 (July 28, 2026)
- Mandiant, M-Trends 2026 (March 23, 2026)
- FIRST, CVSS v4.0 Specification Document
- FIRST, Exploit Prediction Scoring System (EPSS)
- CISA, Stakeholder-Specific Vulnerability Categorization (SSVC)
- CISA, BOD 26-04: Prioritizing Security Updates Based on Risk (June 10, 2026)
- Metabase security advisory for CVE-2026-72898 (August 6, 2026)
- Grafana Labs, Configure anonymous access