At the start of 2026, Hadrian’s Offensive Security Benchmark Report identified a growing mismatch between the volume of vulnerability information available to security teams and their ability to determine which findings represented real risk. Across Hadrian’s dataset, only 0.47% of risks detected by vulnerability scanners were ultimately verified as exploitable and requiring action.

The first half of 2026 has added more pressure to that process. Hadrian’s Exposure Clock shows that an average of 195 new CVEs were published each day during H1, while 15% of incoming CVEs to the National Vulnerability Database still lacked enrichment. Teams are being asked to make prioritization decisions across a larger pool of vulnerabilities, even when some of the contextual information normally used to make those decisions is incomplete.

More vulnerabilities do not necessarily mean more risk

At the H1 2026 rate, approximately 71,314 CVEs are on pace to be published this year. July then set a new monthly record, with 9,771 CVEs published in a single month, while NIST data shows CVE submissions increased 263% between 2020 and 2025.

Those numbers describe growth in disclosed vulnerabilities, not growth in exploitable exposure inside every organization. A CVE may affect software a company does not use, a component that is not internet-facing or a configuration in which exploitation is not possible. Even when a vulnerability is technically relevant, its practical importance depends on where the affected system sits and what an attacker could reach from it.

That leaves security teams with a filtering problem. The number of possible issues is increasing faster than most teams can investigate them individually, while the presence of a CVE alone provides limited information about whether it creates an attack path in a specific environment.

The Exposure Clock illustrates this by separating newly published vulnerabilities from those with a Network attack vector and those subsequently added to CISA’s Known Exploited Vulnerabilities catalogue. Each step adds useful context, but none establishes whether a particular organization is exploitable. That requires connecting public vulnerability information to the organization’s assets, configurations and actual attack surface.

Some of the prioritization data is still incomplete

Vulnerability management depends heavily on enrichment. Teams use information such as severity, affected products, exploitability characteristics and known exploitation to decide what deserves investigation first.

According to the Exposure Clock, 15% of incoming CVEs to the NVD still omit enrichment. That can leave security teams with a published vulnerability record before the additional context they normally use for prioritization is available.

The problem becomes more significant as disclosure volume rises. At an average of 195 new CVEs per day, even a relatively small percentage of incomplete records creates a substantial number of vulnerabilities that require additional research before a team can confidently decide whether they are relevant.

Severity information also has limits when it is available. A CVSS score describes characteristics of a vulnerability, but it does not establish whether the vulnerable software is present in a company’s environment, whether an attacker can reach it or whether exploitation would provide access to something valuable. These questions are specific to the environment and usually require asset context and validation rather than vulnerability metadata alone.

Detection and verification produce very different queues

Hadrian’s benchmark found that only 0.47% of risks identified by vulnerability scanners in its analyzed environments ultimately proved exploitable and required action. The figure comes from Hadrian’s dataset across more than 300 organizations and should not be interpreted as a universal false-positive rate for vulnerability scanners. The underlying analysis included risks that were verified through exploit testing in real environments.

The difference between detection and verification helps explain why security teams can have large vulnerability backlogs while still struggling to identify what needs immediate attention. A scanner may correctly identify a vulnerable software version without being able to determine whether an attacker can access the vulnerable component, satisfy the conditions required for exploitation or chain the weakness with other exposures.

The benchmark’s survey data reflects the same operational problem. More than 70% of security leaders said they struggled to determine which exposures were actually exploitable, while nearly two-thirds cited unverified vulnerabilities as a major source of frustration.

Hadrian’s agentic offensive security platform is designed to take findings further by testing exposures from an attacker’s perspective rather than stopping at detection. The purpose is to provide evidence about what can actually be exploited and what that exploitation allows an attacker to do.

Known exploitation is useful, but it can arrive late

CISA’s Known Exploited Vulnerabilities catalogue gives security teams a strong signal because inclusion means there is evidence that attackers are exploiting a vulnerability in the wild. It is necessarily retrospective, however, because exploitation has to be observed before the vulnerability can be added.

Hadrian’s Exposure Clock records a median period of 57 days between disclosure and a KEV exploitation listing. Hadrian’s benchmark separately cited VulnCheck research showing that 32.1% of Known Exploited Vulnerabilities in 2025 had evidence of exploitation on or before CVE publication.

The two figures describe different stages of the process. Exploitation can begin before or around disclosure, while a widely used confirmation signal can arrive considerably later. A team waiting for KEV inclusion may therefore gain confidence that a vulnerability deserves attention only after attackers have already been using it.

Treating every newly published CVE as an emergency is not a workable alternative when hundreds are appearing each day. Security teams need a way to narrow the gap between those two extremes by establishing whether a vulnerability is present and exploitable in their own environment before external confirmation arrives.

Clear evidence can change remediation speed

Hadrian’s remediation data suggests that organizations are capable of moving quickly when the risk is sufficiently clear. Critical verified exposures had a median remediation time of four days, although the average was 64 days and the slowest 10% took more than 120 days to resolve.

High-severity findings had a median remediation time of 22 days and an average of approximately 140 days. The benchmark attributed part of that difference to the additional effort required to remediate high-severity findings, but also to the organizational urgency created when a risk is clearly understood as critical.

Exploit validation can strengthen that evidence by showing what an attacker is able to do rather than asking teams to act primarily on a severity score. A finding that demonstrates external reachability, successful exploitation and access to a sensitive system provides a clearer reason to interrupt planned work than a vulnerability record that describes only potential impact.

Hadrian’s agentic penetration testing applies this approach by allowing autonomous agents to test potential weaknesses, chain exposures and confirm the resulting attack path. For deeper on-demand testing, Nova uses agentic AI to perform reconnaissance, exploitation and further attack-path testing rather than returning unverified scanner findings.

CTEM programs are still often measuring discovery

The same distinction appears in how organizations measure Continuous Threat Exposure Management. Hadrian’s benchmark found that 67% of organizations measured CTEM success through coverage gaps identified, while only 33% tracked reductions in exploitable exposures over time.

Coverage remains useful because organizations cannot test exposures they do not know exist. The problem arises when discovering more assets and vulnerabilities becomes the outcome rather than the beginning of the process. A program can improve coverage and increase finding volume without establishing whether attackers have fewer viable routes into the organization.

The 2026 benchmark recommended measuring security programs according to verified risk reduction and validating exploitability in real-world conditions. That means following a finding through from detection to confirmed exposure, remediation and retesting rather than measuring success primarily through the number of vulnerabilities or assets discovered.

With vulnerability disclosures continuing to grow and some CVE records arriving without complete enrichment, the distinction between discovery and verification becomes increasingly useful. Security teams need broad visibility, but the operational value comes from reducing the time required to determine which of those findings can actually be used against the organization.

Find out what is actually exploitable

Hadrian continuously discovers external assets and tests potential exposures to determine which weaknesses create real attack paths. Instead of asking security teams to prioritize every new vulnerability equally, validated findings provide evidence of reachability, exploitability and impact.

Explore Hadrian’s approach to agentic offensive security to see how continuous validation can help security teams focus remediation on exposures attackers can actually use.