A CVE is truly exploitable when a working exploit exists, the attacker has access to the vulnerable system, and the configuration of your environment makes the attack path possible. Not every published vulnerability automatically poses a danger. Whether a CVE affects your organization depends on the combination of available exploits, environmental factors, and the likelihood that an attacker takes that specific route. Below we answer the most frequently asked questions about CVE exploitability and vulnerability management.
What determines whether a CVE is genuinely dangerous?
A CVE is dangerous when three elements converge: a working exploit is available, the vulnerable system is reachable by an attacker, and the vulnerability fits within a realistic attack path. If one of these elements is missing, the actual risk drops significantly, even if the theoretical severity of the CVE is high.
Many organizations are overwhelmed by the enormous number of CVEs published each year. In 2026, dozens of new vulnerabilities are documented every day. But the vast majority of them are never actively exploited, simply because attackers choose the path of least resistance. They look for combinations of weaknesses that together form a working attack path, not the most complex exploit.
Exploitability is therefore not a binary property of a CVE itself. It is a property of the interaction between that vulnerability and your specific environment. That is what makes contextual vulnerability research so valuable: only when you understand how an attacker would approach your systems do you know which CVEs are truly dangerous.
What does a CVSS score tell you — and what doesn’t it tell you — about exploitability?
A CVSS score indicates how severe a vulnerability theoretically is, based on factors such as attack vector, complexity, and impact. What the score does not tell you is whether the vulnerability is being actively exploited, whether a working exploit is available, or whether your specific configuration is vulnerable.
The CVSS score is a useful starting point for prioritization, but dangerous as the sole metric. A CVE with a score of 9.8 in software you don’t use is less urgent than a CVE with a score of 6.5 in a system that is directly reachable from the internet. Yet many organizations see a high CVSS score and react as if the impact is automatically significant.
What exactly does CVSS measure?
CVSS looks at the attack vector (network, local, physical), the required complexity of the attack, the privileges needed, and the potential impact on confidentiality, integrity, and availability. These factors are combined into a score between 0 and 10.
What does CVSS miss?
CVSS does not account for the availability of public exploits, active exploitation in the wild, the specific configuration of your environment, or the position of the vulnerability within a broader attack path. These are precisely the factors that determine whether a CVE is actually exploitable for you.
How do you know whether an exploit is being actively exploited in the wild?
You can tell whether an exploit is being actively exploited by consulting threat intelligence sources, such as the CISA Known Exploited Vulnerabilities (KEV) catalog, threat intelligence feeds, and vendor security bulletins. If a CVE appears on the KEV list, proven exploitation is the reason and immediate action is required.
In addition to the KEV list, there are other signals that indicate active exploitation. Security researchers regularly publish proof-of-concept exploits on platforms such as GitHub. Once such an exploit is publicly available, the likelihood of abuse increases significantly, because even less technically skilled attackers can make use of it.
Threat intelligence feeds from vendors such as Recorded Future, Mandiant, or open sources such as NVD and Exploit-DB provide insight into which vulnerabilities are actively being used in attack campaigns. Combining these sources with your own knowledge of your environment is the most reliable way to assess exploitability. This is also why manual pentests go further than automated scans: a human tester combines threat intelligence with knowledge of your specific environment.
Which environmental factors determine whether a CVE affects your organization?
The environmental factors that determine whether a CVE affects your organization are: whether you actually use the vulnerable software, how that software is configured, whether the system is reachable from the network or internet, what privileges an attacker would gain after exploitation, and whether compensating controls such as network segmentation or monitoring are in place.
A CVE in a web server is only relevant if you are running that web server and if it is reachable by potential attackers. If you are running the vulnerable version behind a firewall with no internet connection, the risk is fundamentally different from when that same server is publicly accessible.
Identities and privileges also play a crucial role. Some vulnerabilities require that an attacker already has access to a system or holds certain privileges. In that case, the question is not only whether the CVE is exploitable, but also how difficult it is for an attacker to obtain that initial access. Cloud configurations, permissions, and identity management are just as important as the technical vulnerability itself.
When should you patch a CVE immediately versus accept it?
Patch a CVE immediately when active exploitation has been confirmed, the vulnerability affects a reachable and critical system, and a working patch is available. Accept or defer a CVE when the vulnerable system is not reachable, no working exploit exists, or the cost of patching is disproportionate to the actual risk.
A structured approach to this decision combines three factors: the CVSS score as a baseline, the presence of active exploitation as an accelerator, and the environmental context as the determining factor. If a CVE is on the CISA KEV list and affects a reachable system in your environment, immediate action is always justified.
Accepting a CVE is a deliberate risk decision, not a deferral. Document why you decide to accept a vulnerability, what compensating controls are in place, and when you will revisit the decision. This keeps patch management a controlled process rather than a reactive firefighting exercise.
Why is an annual scan not sufficient for CVE management?
An annual scan is not sufficient for CVE management because your environment changes continuously. New software is installed, configurations are adjusted, accounts and privileges change, and new vulnerabilities are published every day. An annual scan gives you a snapshot of a single day, while attackers are active 365 days a year.
Suppose you run a scan in January and resolve all findings. In March, a critical CVE is published in software you use. In May, that CVE is being actively exploited. Without continuous visibility, you only find out at the next annual scan that you have been vulnerable — and that is precisely the period during which attackers strike.
Vulnerability management is not a project but an ongoing process. It requires monitoring for new CVEs, regular reassessments of your environment after changes, and a mechanism to respond quickly when active exploitation is detected. Continuous testing aligns with this reality: not a single snapshot of a moving target once a year, but continuous insight into what your environment looks like from an attacker’s perspective.
How Q-Cyber helps with CVE prioritization and vulnerability management
At Q-Cyber, we understand that the biggest challenge in CVE management is not finding vulnerabilities, but determining which ones actually matter. Our approach goes beyond a list of findings and focuses on the question that truly matters: which vulnerabilities form a realistic attack path in your specific environment?
- Manual pentests in which our ethical hackers think like an attacker, including combining CVEs with misconfigurations, identities, and permissions into working attack paths
- Contextual risk analysis that goes beyond CVSS scores and takes into account your environmental factors, reachability, and active exploitation
- Continuous insight through our Continuous-Q® program, so you know where you stand not only on the day of testing, but throughout the entire year
- Concrete prioritization with a clear distinction between vulnerabilities that require immediate action and vulnerabilities that are acceptable with compensating controls
- Independent advice without dependency on software vendors, so our recommendations are always in your best interest
Want to know which CVEs in your environment are truly exploitable? Get in touch and we will discuss which approach best fits your situation.