The difference between severity and exploitability determines how dangerous a vulnerability truly is in practice. Severity describes the potential impact if a vulnerability is exploited, while exploitability indicates how easily an attacker can actually carry out that exploitation. Both scores together provide a far more realistic picture of risk than either one alone. In this article, we answer the most important questions about how to interpret these scores and how to set the right priorities based on them.
How do you determine which vulnerability is the most dangerous?
The most dangerous vulnerability is not automatically the one with the highest severity score. A vulnerability is only truly dangerous when it both has a large potential impact and is relatively easy for an attacker to exploit. The combination of severity and exploitability determines the actual risk to your organization.
Many organizations make the mistake of looking exclusively at the severity of a vulnerability on paper. A vulnerability with a critical CVSS score of 9.8 sounds alarming, but if that vulnerability can only be exploited from an internal network that no attacker has access to, the actual risk is considerably lower. Conversely, a vulnerability with a lower score can be urgent if it is easily exploitable remotely and provides access to sensitive systems.
Attackers do not think in lists of findings. They look for the path of least resistance: the combination of weaknesses that gets them to their goal the fastest. This means that when assessing vulnerabilities, you should always ask: how does this finding fit into a broader attack chain?
What exactly does the CVSS score measure?
The CVSS score, or Common Vulnerability Scoring System score, is a standardized method for measuring the severity of a vulnerability on a scale of 0 to 10. The score combines multiple factors, including the attack vector, the required privileges, user interaction, and the impact on confidentiality, integrity, and availability.
The CVSS score is built from three groups of metrics:
- Base metrics: the inherent properties of the vulnerability itself, such as whether it can be exploited remotely and what impact it has on a system
- Temporal metrics: factors that change over time, such as the availability of a public exploit or a patch from the vendor
- Environmental metrics: adjustments based on the specific environment of your organization, such as how critical the affected system is
In practice, most tools and reports use only the base score, without taking into account temporal or environment-specific context. This makes the score useful as a first indication, but insufficient as a basis for prioritization. A CVSS score says something about the potential severity of a vulnerability, but nothing about the specific situation of your organization or the likelihood that an attacker will actually exploit that vulnerability.
Why does a critical severity sometimes have low priority?
A critical severity score does not always justify immediate action, because the score does not take into account the specific context of your environment. If a vulnerability with a high CVSS score can only be exploited via direct physical access, or only applies to software you do not use at all, the actual threat is minimal.
There are several reasons why a vulnerability with a high severity score may still receive low priority:
- The affected system is not reachable from the internet or from the network segment where an attacker is located
- There is no known public exploit for the vulnerability
- Compensating controls are active, such as network segmentation or additional authentication requirements
- The system contains no sensitive data and is not critical to business operations
- The vulnerability requires a high level of privileges that an attacker realistically does not have
This is precisely why manual pentesting is more valuable than a purely automated vulnerability scan. A scanner reports based on the CVSS score; an experienced tester assesses whether a vulnerability is actually exploitable in your specific environment.
How do attackers use exploitability when choosing a target?
Attackers evaluate exploitability as one of the first filters when choosing an attack path. They look for vulnerabilities that are remotely exploitable, require no or minimal privileges, require no user interaction, and for which public exploits or tools are available. The lower the barrier, the more attractive the target.
A good example is the difference between a vulnerability that an attacker can exploit remotely without any authentication, and a vulnerability that only works if the attacker already has administrator privileges. The first has high exploitability and immediately attracts the attention of automated attack tools and opportunistic attackers. The second requires the attacker to already be deep inside the system, which raises the barrier considerably.
What attackers also do — and what is often missed in traditional risk assessments — is combining multiple vulnerabilities with a low individual severity into one working attack path. A misconfigured cloud setting, combined with overly permissive permissions and a weak identity configuration, can together lead to full access to cloud resources, while none of the three findings is considered critical on its own. Attackers do not see isolated findings. They see attack paths.
What factors determine whether a vulnerability is truly exploitable?
Whether a vulnerability is actually exploitable depends on a combination of technical and environment-specific factors. The most important ones are the attack vector, the required privileges, the availability of a working exploit, and the presence of compensating security controls in your specific environment.
The key factors at a glance:
- Attack vector: is the vulnerability exploitable via the internet, via the local network, or only with physical access?
- Required privileges: does an attacker already need an account or administrator access to exploit the vulnerability?
- User interaction: does a user need to click or open something before the exploit works?
- Availability of exploits: does a public, working exploit exist, or is the technical knowledge required to write one limited?
- Compensating controls: are there firewalls, network segmentation, MFA, or other controls that reduce exploitability?
- Patch status: is a patch already available, and how quickly is it deployed within your organization?
Assessing all these factors together requires insight into how your environment is set up. A thorough security analysis goes beyond checking off CVE scores and assesses vulnerabilities in the context of your specific architecture, identities, and permissions.
How do you prioritize vulnerabilities based on both scores?
Effective vulnerability prioritization combines severity and exploitability in a risk model that also takes into account the context of your organization. The rule of thumb: prioritize vulnerabilities that both have a high impact and are relatively easy to exploit, and factor in how critical the affected system is to your business operations.
A practical framework for prioritization works in three layers:
- Known vulnerabilities with public exploits: CVEs with a high CVSS score and an available public exploit require immediate action. These are the low-hanging fruit for attackers and should be addressed first.
- Individual weaknesses in configuration and identities: misconfigured cloud settings, overly permissive permissions, and weak identity configurations often have a lower CVSS score but high exploitability in practice. They deserve a higher priority than their score suggests.
- Correlated attack paths: the most dangerous category is often the combination of multiple small weaknesses that together form an attack path. No single finding appears critical on its own, but together they can lead to full access to systems or cloud resources.
When prioritizing, it is also important to consider which systems are most attractive to attackers and which are most critical to your organization. A vulnerability in an internal test system has a different priority than the same vulnerability in a production environment containing customer data.
Annual pentests provide a snapshot, but the environment changes continuously. New applications, modified permissions, and new vulnerabilities mean that a prioritization list quickly becomes outdated. Continuous insight into attack paths is therefore not a luxury but a necessity for organizations that take their security seriously.
How Q-Cyber helps assess severity and exploitability
At Q-Cyber, we believe that a list of vulnerabilities only has value when you understand which of them are truly exploitable in your specific environment. That is why we assess vulnerabilities not only based on CVSS scores, but in the context of your architecture, identities, permissions, and attack paths.
What we concretely do:
- We conduct manual pentests in which our ethical hackers think like a real attacker, including identifying correlated attack paths that automated scanners miss
- We assess vulnerabilities at three levels: known CVEs, individual weaknesses in configuration and identities, and combined attack paths
- We deliver concrete prioritization based on both severity and actual exploitability in your environment, not based on generic scores
- We provide continuous insight through Continuous-Q®, so you know where you stand not just on the day of the test but throughout the entire year
- We give pragmatic advice on which measures eliminate the most risk, independent of software vendors or suppliers
Want to know which vulnerabilities in your environment are truly exploitable and how to best prioritize them? Contact us and we will be happy to think along with you.