How to detect non-CVE vulnerabilities that standard scanners miss

If your application security program only tracks known Common Vulnerabilities and Exposures (CVEs), you’re probably missing a large share of your real risk.

Across the Detectify platform, 75% of the vulnerabilities in our test catalog and 99% of those we discover in customers’ assets are non-CVE vulnerabilities.

That makes public disclosures a poor measure of coverage on a modern attack surface. Below, we look at why so many vulnerabilities never get a CVE and how Detectify finds both kinds.

Why do some vulnerabilities have no CVE?

The CVE program is a foundation of the security industry, but it was built to catalog flaws in distributed software. A lot of what goes wrong in cloud-native web applications falls outside that scope, and scanners that lean mostly on CVE databases tend to miss it for a few reasons.

• Custom code and SaaS flaws. Bugs in custom web apps, business logic, path-based cross-site scripting (XSS) or specific software configurations rarely get a public CVE ID, since there’s often no vendor product to file them against.
• Slow disclosure. Getting a CVE assigned involves vendor coordination, triage, and paperwork. By the time it’s published and someone writes a public scanner template, attackers may have been using the flaw for weeks.
• Misconfigurations and subdomain takeovers. SSL/TLS hostname mismatches, expired certificates, and dangling DNS records are serious risks, yet they generally don’t qualify for a CVE.
• Too much weight on CVSS scores. When vulnerability management is sorted by CVSS, engineers end up chasing high-scoring CVEs that may have no working exploit, while exploitable issues without a CVE go unnoticed.

How Detectify sources vulnerabilities

To close that gap, Detectify feeds three research sources into one payload-based scan engine:

• Detectify Crowdsource, our private network of ethical hackers, which supplies most of our novel and non-CVE research.
• Our internal security research team, which digs into complex systems, API frameworks and new threat vectors, and builds specialized fuzzing logic.
• Alfred, our AI security researcher, which turns public CVE disclosures into automated tests.

1. Detectify Crowdsource

Most of our non-CVE detection starts with Detectify Crowdsource, an invite-only community of ethical hackers and security researchers from around the world. Here’s how it works:

• A researcher finds a new attack technique or zero-day in the wild and submits it to Detectify.
• Our team turns the submission into an automated, payload-based scanning module.
• Each time that module finds a vulnerability on a customer asset, the researcher who submitted it gets paid. Researchers earn more when their work protects more systems, which keeps everyone focused on coverage that matters in practice.

2. In-house security research

Our security research team spends its time on emerging web technologies, API frameworks and new kinds of attack surface. They write fuzzing logic and detection modules for the subtle issues that signature-based scanners tend to overlook.

3. Alfred, our AI security researcher

Public disclosures arrive faster than any human team can process them, so Alfred handles the volume. It continuously ranks newly disclosed CVEs by exploit likelihood (EPSS), relevance to customer assets, and threat actor intelligence. This means that CVEs that active groups are exploiting right now will receive coverage first. Alfred AI then analyzes public proofs of concept, turning them into payload-based tests crafted for Detectify. At the end of the procesa human researcher reviews every test before it goes live.

How does payload-based testing reduce false positives?

Finding non-CVE vulnerabilities only helps if your team can act on the results. Many CVE scanners rely on version-string matching, for example, flagging a server because its banner reports an outdated Apache version. That approach produces a lot of false positives.

Detectify uses payload-based testing instead. We only report a vulnerability after a safe payload runs successfully and proves the issue can be exploited. Your team gets high-confidence alerts with clear next steps, whether or not the finding has a CVE identifier.

The fix ships with the test

Every finding comes with a risk level, a description and references so your team can prioritize. For new critical and high-severity vulnerabilities, our researchers write remediation guidance at the same time as the test, so your engineers get a concrete fix instead of a link to a Wikipedia article. For older tests, Alfred is backfilling remediation across the catalog. And if your team needs a hand, our customer success team works as an extension of yours.

Looking past the CVE list

When you stop treating the CVE list as the full picture, you cut down on noisy false positives and start covering the 75% of vulnerabilities that public databases never catalog.

How to detect non-CVE vulnerabilities

To detect non-CVE vulnerabilities, you need to test how your applications actually behave, cover every asset you expose, and use research sources beyond public CVE feeds. These five steps cover the essentials:

1. Test with real payloads instead of software version checks. Send safe payloads that try to exploit the vulnerability, and only treat a finding as confirmed when the payload works. Version matching can only flag issues that already have a CVE.
2. Map your full external attack surface, including forgotten subdomains and root domains. You can’t test assets you don’t know about, and old marketing sites, staging environments and acquired domains are common places for unpatched issues.
3. Monitor DNS for dangling records that allow subdomain takeovers. A DNS record that still points to a deleted cloud resource lets an attacker claim that resource and serve content from your domain.
4. Bring in research from outside CVE feeds, such as ethical hackers and in-house research. New attack techniques are often known to researchers months before a CVE is published, if one is published at all.
5. Prioritize by exploitability, not CVSS score alone. A confirmed, exploitable misconfiguration deserves more attention than a high-scoring CVE with no working exploit.

FAQ

What is a non-CVE vulnerability?

A non-CVE vulnerability is a security flaw that has no entry in the public CVE database. Common examples include business logic bugs in custom applications, misconfigurations, expired certificates and subdomain takeovers caused by dangling DNS records.

Are non-CVE vulnerabilities less dangerous than CVEs?

Not necessarily. Whether a flaw has a CVE says nothing about how severe it is. A subdomain takeover or a logic flaw in a login flow can be just as damaging as a critical CVE, and it may stay exposed longer because fewer tools look for it.

Why don’t standard scanners find them?

Many scanners match software versions against CVE databases. If a flaw has no CVE, or lives in code that only your organization runs, there’s nothing for the scanner to match against.

How does Detectify find vulnerabilities that have no CVE?

Most of our non-CVE coverage comes from Detectify Crowdsource, where ethical hackers submit new techniques that we turn into automated tests. Our internal research team adds detection for new technologies and attack surfaces.

How does Detectify avoid false positives?

We use payload-based testing. A finding is only reported after a safe payload proves the vulnerability can be exploited, which removes most of the guesswork that comes with version matching.