# What is exploitability? How deployment context shapes vulnerability risk _Exploitability measures how feasible it is to use a vulnerability. Contextual exploitability checks whether the necessary conditions exist in your deployment._ ## What is exploitability? Exploitability measures how feasible it is for an attacker to use a vulnerability to gain unauthorized access, execute code, or disrupt a service. While vulnerability impact measures what damage occurs if an attack succeeds, exploitability measures the barrier to entry, including required privileges, network positioning, and technical prerequisites. Success may require an authenticated account, elevated privileges, a particular configuration, or another user opening a file. Some attacks also depend on timing or a specific execution state. Contextual exploitability checks whether those requirements are met in your environment. A vulnerable package, for example, may have its affected feature disabled or inaccessible from the attacker’s starting point. That distinction helps you prioritize affected workloads and explain the decision to their owners. The [Common Vulnerability Scoring System (CVSS)](https://www.wiz.io/academy/vulnerability-management/what-is-cvss-common-vulnerability-scoring-system) describes these prerequisites through its exploitability metrics. In CVSS v3.x, four Base metrics provide the starting point: - **Attack Vector **describes the access needed: network, adjacent network, local, or physical. - **Attack Complexity** captures conditions beyond the attacker’s control that must hold for exploitation to succeed. - **Privileges Required** describes the access rights needed before exploitation, separate from any privileges gained through it. - **User Interaction **indicates whether someone other than the attacker must participate in a successful attack. [CVSS v4.0](https://www.first.org/cvss/v4.0/specification-document) adds **Attack Requirements** to distinguish deployment or execution prerequisites from the effort needed to bypass security mechanisms. These metrics explain how a weakness works, giving you specific conditions to check against a workload’s configuration and access paths. Public exploit code adds another piece of evidence by showing how the weakness can be used under particular conditions. Those conditions still need to match your workload before you conclude that it is exploitable. Equally, the absence of published code does not rule out exploitation. ## How does exploitability differ from vulnerability severity? Exploitability is one part of severity. CVSS Base combines intrinsic exploitability and impact under reasonable worst-case assumptions, giving teams a consistent way to describe a weakness. Remediation priority adds the affected asset’s context and the consequences of a successful attack. CVSS can incorporate some of that context: v4.0 Threat metrics account for exploit maturity, while Environmental metrics reflect the organization’s environment and security requirements. Supplemental metrics add information without changing the score. If a finding includes only a Base Score, those refinements are absent, so prioritization still requires checking network paths, effective permissions, and enforced protections. A hypothetical comparison shows why this matters. Two Amazon EC2 instances have the same [server-side request forgery (SSRF)](https://www.wiz.io/academy/application-security/server-side-request-forgery) vulnerability, which lets an attacker make an application send requests to unintended destinations. Their deployments, however, give the attacker different opportunities. The first application is internet-accessible. Assume the SSRF weakness permits simple requests to the instance metadata service and returns its responses. Instance Metadata Service v1 (IMDSv1) is allowed, and an attached identity and access management (IAM) role has broad permissions. Together, these conditions can expose the role’s temporary credentials. The application provides the route to metadata, so the metadata service itself need not be internet accessible. With those credentials, the attacker can attempt actions allowed by the role, extending the attack beyond the application. By contrast, the second application runs in an isolated [virtual private cloud (VPC)](https://www.wiz.io/academy/cloud-security/virtual-private-cloud-vpc), with no external route to it and no attached workload IAM role. The external credential-theft path described above is absent, although internal access paths and other SSRF targets still need assessment. The software flaw remains, but the two deployments can justify different remediation priorities. ### What do EPSS, KEV, and SSVC tell us? Deployment evidence explains the local path; threat signals help establish urgency. The [Exploit Prediction Scoring System (EPSS)](https://www.first.org/epss/faq) estimates the probability that exploitation activity for a CVE will be observed in the wild within 30 days. Updated daily, it does not predict whether a particular workload will be compromised. Its probability and percentile answer different questions. A hypothetical probability of 0.10 means an estimated 10% chance of observed exploitation during that window. A 95th-percentile ranking only describes the vulnerability’s position relative to others; it doesn’t mean a 95% probability of exploitation. Where EPSS predicts activity, the [CISA Known Exploited Vulnerabilities catalog (KEV)](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) identifies vulnerabilities with evidence of exploitation in the wild. Inclusion warrants attention to affected assets, but absence is not evidence of safety. Either way, local prerequisites and protections still matter. CISA’s [Stakeholder-Specific Vulnerability Categorization (SSVC)](https://www.cisa.gov/sites/default/files/publications/cisa-ssvc-guide%20508c.pdf) then provides a decision framework that considers exploitation information alongside organizational consequences. These inputs help determine urgency, while deployment evidence establishes whether the relevant path exists in your environment. ## How does deployment context change exploitability? The EC2 example separates two questions: Can the attacker exploit the workload, and what could they reach afterward? Assessing both requires a connected view of network access, identity permissions, controls, and data. ### Which environmental factors matter? Network reachability establishes whether an attacker can connect to the vulnerable service from a specified starting point: the internet, a partner network, or an internal foothold. Within the application itself, package and function reachability determine whether the vulnerable code is actually loaded into memory and called during execution, or if it remains dormant dead code. Follow the external route through gateways, network rules, and application access controls, remembering that a blocked internet route may still leave access open from a compromised internal workload. Once access is established, [effective IAM permissions](https://www.wiz.io/academy/cloud-security/effective-permissions) help determine what the compromised identity could do. This depends on applicable identity and resource policies, organizational restrictions, permission boundaries, session limits, and explicit denies, with evaluation rules varying by provider. Check the resulting authorization rather than role names alone, including whether the identity can assume another role or modify a resource with greater privileges. A feasible-looking route may still be interrupted by compensating controls. To rely on a control, verify that it’s enforced on the affected resource and blocks a requirement of the specific attack. An inventory entry alone is insufficient. For example, requiring IMDSv2 blocks the simple GET-only SSRF-to-metadata path above because it requires a token obtained through a PUT request and supplied with subsequent requests. Merely supporting IMDSv2 while allowing IMDSv1 leaves that protection unenforced. Requiring it blocks the described path, but does not fix the SSRF flaw or rule out every technique. For paths that remain feasible, data sensitivity and blast radius describe the consequences. Blast radius is the scope of systems, identities, and data reachable from the initial compromise, including through lateral movement. Access to customer records can therefore make an attack more urgent than access limited to public content, even when the initial exploit is equally easy. ### How do toxic combinations create attack paths? These factors become most useful when assessed together. Wiz describes interacting risk factors as [toxic combinations](https://www.wiz.io/blog/the-anatomy-of-a-toxic-combination-of-risk): exposure, permissions, and data access can connect a vulnerability to valuable resources. An internet-facing service or IAM role is not necessarily a vulnerability itself; the risk comes from the usable path they form with a weakness. Consider a hypothetical internet-accessible container with a moderate-severity code-execution vulnerability. Assume an attacker can reach the affected functionality, meet the exploit’s prerequisites, and access credentials for a broadly privileged workload role through the compromised process. If those credentials authorize reads from sensitive storage, the chain extends from code execution in one container to data elsewhere in the environment. Each connection needs evidence: How does the process obtain credentials, and what do they authorize? Simply finding a vulnerable image, privileged identity, and sensitive data in one account doesn’t prove a chain. Once the path is established, it can justify prioritizing this moderate-severity finding ahead of a higher-scored issue. Teams can then patch the component, restrict the entry point, or reduce permissions, and verify that the chosen fix breaks the path. ## How can teams use exploitability to prioritize findings? To turn attack-path analysis into consistent decisions, apply the same four steps to each affected instance: 1. **Confirm applicability: **Identify the resource, component, version, and affected feature. Establish that the vulnerability applies to this deployment before investigating its attack path. 1. **Assess the path**: Record the attacker’s starting point, required access, and exploitation prerequisites. Distinguish a verified absent condition from a condition you have not checked. 1. **Verify controls and impact**: Test the relevant protections, then examine effective permissions, reachable data, and business consequences. Keep initial exploitability separate from downstream impact. 1. **Record the action**: Capture evidence, uncertainty, assessment time, an accountable owner, and the planned response. Set review triggers so the decision can change with the environment. A shared asset record helps teams apply these steps consistently. If five scanners report the same CVE, reconcile their component identification, scoring versions, metric choices, and assumptions before comparing severity labels. The reports may describe one underlying path rather than five separate risks. Building that record also means bringing together network topology, IAM, and data classification from tools that may not integrate or reflect the same point in time. Identify those gaps explicitly: unknown reachability requires investigation and should not be recorded as a blocked route. Wiz’s [State of Cloud Risk 2026](https://www.wiz.io/reports/state-of-cloud-risk-2026) reports that, across the environments studied, contextual analysis eliminated more than half of initial high-severity findings across four major risk categories. This illustrates how connecting findings to deployment conditions can sharpen priorities and help teams focus on the attack paths that matter most. For an individual finding, deprioritization needs a specific explanation. For example, an enforced control blocks the assessed external path. Keep the vulnerability tracked, with supporting evidence and a review trigger, so teams can address more consequential paths first without losing accountability for the rest. ## Why does exploitability change over time? Exploitability changes over time because deployment conditions and attackers’ capabilities evolve. A new network route can expose a service, expanded permissions can put more data within reach, and a disabled control can reopen a path. New exploit code or reports of active exploitation can also change urgency without changing the CVSS Base Score. For this reason, [vulnerability prioritization](https://www.wiz.io/academy/vulnerability-management/vulnerability-prioritization) needs reassessment after deployments, permission or control changes, and new exploitation evidence. Pair those triggers with periodic reviews to catch missed changes, and give each triage decision an expiry or review condition. The same approach applies across AWS, Azure, and Google Cloud, where different identity relationships, network paths, and dependencies can give the same vulnerability different priorities. Evaluate each deployment using its provider’s authorization rules, then revisit the remediation order as those conditions change. ## Prioritize exploitable risk from code-to-cloud and runtime Sifting through thousands of vulnerability alerts to find genuinely exploitable risk across cloud, on-prem, and hybrid environments is the challenge Wiz addresses. Wiz Vulnerability Management replaces isolated CVSS scores with multidimensional context, automatically enriching every finding with live [threat intelligence](https://www.wiz.io/academy/threat-intel/what-is-threat-intelligence), including EPSS probabilities, CISA KEV status, and public exploit availability. To determine whether a vulnerability is contextually exploitable, Wiz analyzes reachability across multiple layers. In application code, Wiz Code reachability analysis verifies whether a vulnerable function in an open-source dependency is called by first-party code or remains unreferenced. At runtime, the [Wiz Runtime Sensor](https://www.wiz.io/solutions/runtime-sensor) validates whether vulnerable packages and libraries are actively loaded into memory and executing. On the external perimeter, Wiz Attack Surface Management and the Wiz Red Agent conduct active exploitability validation. They safely probe exposed web applications and APIs to verify whether vulnerabilities and misconfigurations can be triggered from the outside. The [Wiz Security Graph](https://www.wiz.io/platform/wiz-cloud) connects these findings to your broader cloud infrastructure. Instead of alerting on software flaws in isolation, Wiz surfaces toxic combinations: an exploitable vulnerability linked to public network exposure, high-privilege IAM permissions, and sensitive data. Correlating these factors turns thousands of noisy CVEs into a focused set of prioritized Issues representing real attack paths. This multi-layered context gives security and engineering teams the confidence to act on what matters. [Request a demo](https://www.wiz.io/demo) to see how Wiz connects threat intelligence, reachability, and cloud context to prioritize and remediate exploitable attack paths across your environment. ## FAQs --- [View on wiz.io](https://www.wiz.io/academy/vulnerability-management/what-is-exploitability)