Yes, a security risk can certainly exist without a known CVE. A CVE (Common Vulnerabilities and Exposures) is an officially registered vulnerability in software or hardware, but not every risk makes it into that database. Misconfigurations, weak access permissions, insecure architectural choices, and logical flaws in processes represent real attack vectors that never receive a CVE number, yet are actively exploited by attackers.
This distinction is crucial for organizations that base their security solely on CVE lists or automated scanners. That approach covers only a portion of the actual attack surface. In this article, we answer the most frequently asked questions about security risks without a known CVE, how attackers find them, and how you can detect them yourself.
What counts as a security risk when there is no CVE?
A security risk without a CVE is any weakness in a system, process, or environment that an attacker can exploit to gain access, cause damage, or steal data — even if that weakness has never been officially registered as a vulnerability. CVEs cover software flaws in known products, but an organization’s attack surface is much broader than that.
Concrete examples of security risks without a CVE include:
- Misconfigurations: cloud storage that is accidentally publicly accessible, a firewall with overly permissive rules, or an admin account without multi-factor authentication
- Overprivileged accounts: users or service accounts with more permissions than necessary, allowing an attacker to achieve a great deal immediately after a compromise
- Logical flaws in processes: a password reset flow that is too easy to bypass, or an API that makes assumptions about who is logged in
- Supply chain access: vendors or MSPs with direct access to systems, without that access being properly monitored or restricted
- Weak segmentation: a network where an attacker who compromises one system can move laterally almost unimpeded
All of these risks are real, exploitable, and dangerous — yet they never appear in a CVE database. An organization that focuses solely on CVEs has a blind spot the size of its own architecture.
How do attackers discover vulnerabilities without a CVE?
Attackers discover vulnerabilities without a CVE not by searching for known software flaws, but by understanding how an organization is structured. They start with reconnaissance: who works there, which vendors have access, which services are publicly visible, and what identities and permissions exist within the environment? Only then do they look for the weakest link in the whole.
An attacker looks for combinations of weaknesses that may seem harmless individually, but together form an attack path. For example, an account with excessive privileges, combined with a poorly configured VPN and a vendor with unrestricted access, can yield a complete attack path without a single CVE being involved.
What helps attackers here is publicly available information: LinkedIn profiles, job postings, technical documentation, certifications, and even job advertisements often reveal which systems and vendors an organization uses. A skilled attacker can learn a great deal about the environment before taking a single technical step. This is precisely why red team exercises are so valuable: they simulate this entire thought process, including the reconnaissance phase.
What is the difference between a zero-day and a vulnerability without a CVE?
A zero-day is a specific type of vulnerability: a software flaw that is still unknown to the vendor and for which no patch yet exists. A vulnerability without a CVE is a broader category: it encompasses everything that poses an attack risk but has not been registered as a software vulnerability, such as misconfigurations, architectural flaws, and weak processes. Every zero-day is temporarily a vulnerability without a CVE, but not every vulnerability without a CVE is a zero-day.
The distinction is practically relevant. A zero-day is rare, technically complex, and is often used in targeted attacks against large organizations or governments. Vulnerabilities without a CVE in the broader sense — such as an overprivileged service account or a poorly configured cloud environment — occur in virtually every organization and are exploited daily by attackers of all levels.
For most organizations, the risk of non-CVE vulnerabilities in the second category is therefore greater than the risk of zero-days. The first category is manageable with good configuration practices, access management, and regular testing. A zero-day is by definition harder to prevent, but also less likely to be an attack vector for the average organization.
Why do traditional vulnerability scans miss non-CVE risks?
Traditional vulnerability scans miss non-CVE risks because they are designed to recognize known software flaws, not to reason like an attacker. A scanner compares what it finds against a database of known CVEs and technical deviations. What is not in that database is not reported, regardless of how significant the actual risk is.
This has a number of direct consequences:
- A misconfiguration in a cloud platform is not flagged as a vulnerability if there is no associated CVE
- Logical flaws in applications — such as an authorization issue in a business process — fall outside the scope of automated tools
- Combinations of weaknesses that together form an attack path are not recognized because a scanner assesses each element separately
- Identity and permission issues, such as accounts with excessive privileges, are rarely picked up by standard scanners
The danger is not that a vulnerability scan is useless. For checking basic hygiene and quickly identifying known technical flaws, a scan certainly has value. The danger is that organizations think a clean scan report equals a secure environment. That is a misconception that attackers are happy to exploit. More background on the limitations of automated tools can be found in our cyber research overview.
How do you test for security risks without a known CVE?
To test for security risks without a known CVE, you need an approach that thinks like an attacker rather than like a scanner. That means manual testing by experienced specialists who explore the environment, construct attack paths, and identify logical weaknesses that fall outside the CVE database.
Concretely, there are three levels at which you can address this:
Manual penetration testing
In a manual pentest, ethical hackers investigate the environment the way an attacker would. They look not only at software flaws, but also at configurations, access permissions, architectural choices, and the way systems communicate with each other. This yields findings that a scanner structurally misses.
Red team exercises
Red teaming goes a step further: a team of attackers simulates a full attack campaign, including reconnaissance, social engineering, and lateral movement through the network. The goal is not a list of vulnerabilities, but demonstrating whether an attacker can actually achieve their objective. This type of test surfaces combinations of weaknesses that might remain invisible in a standard pentest.
Continuous monitoring and testing
A one-time test provides a snapshot. Because environments change constantly — accounts are added and configurations are adjusted — continuous testing is the most effective approach. The environment is regularly retested so that new risks are identified quickly before an attacker discovers them.
When is an annual pentest not enough?
An annual pentest is not enough when an organization’s IT environment changes throughout the year — which is the case for virtually every organization. New applications, cloud resources, accounts, vendor integrations, and configuration changes continuously create new attack vectors. A pentest that yields a clean result today says nothing about the situation three months from now.
Attackers also do not operate on an annual schedule. New attack techniques are developed and deployed throughout the year. A vulnerability that arises in February due to a configuration change can already be exploited in April, long before the next annual test takes place. An annual pentest is in that sense a photograph of a moving target: useful as a baseline, but insufficient as the sole security measure.
Specific situations in which an annual pentest demonstrably falls short:
- After every significant change to the IT infrastructure, such as a cloud migration or a new SaaS integration
- When new vendors or MSPs gain access to systems
- After changes to access permissions or the introduction of new accounts
- When the organization grows and new employees, systems, or locations are added
- After a security incident, even if that incident seemed minor
For organizations that want to continuously know whether their security holds up, a model of continuous penetration testing is the logical next step. This shifts the question from “were we secure on the test date?” to “are we secure today?”
How Q-Cyber helps with security risks without a known CVE
At Q-Cyber, we understand that the most dangerous risks often do not appear in a CVE database. Our approach is therefore not based on automated scanning, but on thinking and working like a real attacker. We help organizations map their full attack surface, including the risks that traditional tools structurally miss.
What we concretely do:
- Manual pentests: our ethical hackers investigate configurations, identities, permissions, and attack paths — not just known software flaws
- Red team exercises: we simulate a full attack campaign to test whether an attacker can actually achieve their objective
- Continuous-Q®: our continuous testing programme ensures that new risks are identified quickly, even between annual tests
- Independent advice: we are not tied to software vendors, which means our findings are always objective and pragmatic
Want to know which risks your organization faces that fall outside the scope of standard scanners? Contact us for a no-obligation conversation.