New research from Cogent Security analyzed 69,159 CVEs published between January 2025 and April 2026, tracking the timeline between public disclosure, exploit availability, and scanner detection signature release across three major vulnerability management platforms: Tenable, Qualys, and Rapid7. The findings quantify a shift that security practitioners have felt anecdotally but lacked longitudinal data to prove: scanner-based visibility now lags behind the threat it was designed to detect.

What Happens When 83% of Critical Vulnerabilities Create a Visibility Gap

Among critical vulnerabilities with known exploits, 62.0% had working exploit code circulating in public repositories or underground forums before any of the three scanner platforms released a detection signature. That figure describes a scenario in which organizations running continuous vulnerability scans (a baseline control in most enterprise security programs) remained blind to exposures that adversaries could already leverage.

The visibility problem extends beyond detection lag. More than half (55.7%) of critical CVEs received no scanner coverage from Tenable, Qualys, or Rapid7 at any point during the 16-month research window. In practice, that means security teams operating on the assumption that their scanner output represents a complete inventory of critical exposures are making remediation decisions based on partial data.

When the two conditions are combined (CVEs that never received scanner coverage and CVEs where exploits arrived before signatures shipped), 83.2% of critical vulnerabilities either lacked detection entirely or had exploits available during the period when scanning infrastructure provided no visibility. That number reflects the percentage of critical exposures for which traditional scanner-based workflows cannot serve as the primary detection mechanism during the highest-risk period following disclosure.

“The assumption that security teams have days or weeks to respond to a new CVE is no longer valid,” said Geng Sng, CTO and co-founder at Cogent. “We tracked over 69,000 CVEs across 16 months and watched the average time to exploit fall from over four months to less than twelve hours. Scanner vendors are not closing that gap at the same rate.”

The operational consequence is straightforward: organizations that treat scanner output as the starting point for incident response are reacting to threat intelligence that arrives after the initial exposure window has opened. For vulnerabilities disclosed on a Friday afternoon, that delay can mean an entire weekend during which exploitation proceeds without detection infrastructure in place.

How AI Compressed the Exploit Development Timeline by 99.6%

The acceleration in exploit availability is not incremental. In January 2025, the average time from CVE publication to the first publicly available exploit was 125.3 days. By April 2026, that window had collapsed to 0.5 days: a reduction of more than four months compressed into a span of fewer than 16 months.

The impetus behind this change is AI-assisted exploitation. Today, it becomes possible to feed large language models trained on information from vulnerability databases, exploits, and reverse engineering techniques with a vendor-published patch diff to create proof-of-concept code in a matter of hours. This approach completely cuts off manual analysis of the vulnerability and subsequent coding efforts necessary to craft a reliable exploit. What used to take several days of effort from highly-skilled reverse engineers is accomplished within seconds in a single LLM inference process.

The time savings effect is maximized for cases of critical and high-severity vulnerabilities, where the combination of public interest, exploitability, and existence of a patch diff make conditions optimal for automation tools to do their job. Critical vulnerabilities don’t need any further efforts from security professionals to provide a proof-of-concept code and exploit generation.

“When it takes five or six days for a vulnerability to show up in your scanner, you’re giving attackers a week-long head start,” said Scott Howitt, former CISO of MGM Resorts and JCPenney. “They’re reading the same disclosures we are and moving on them within hours.” That observation captures the asymmetry: defenders and adversaries receive the same disclosure information at the same time, but only one side has infrastructure capable of operationalizing that intelligence within a sub-24-hour window.

Scanner Vendor Performance Varies, but All Trail Exploit Availability for Most Critical CVEs

The research measured median detection lag (the time from CVE publication to scanner signature release) across the three platforms. Tenable delivered the fastest median response at 0.1 days, followed by Qualys at 2.9 days and Rapid7 at 5.1 days. Those figures represent the midpoint: half of all signatures arrived faster, half slower.

Median performance, however, obscures the distribution that matters most to security teams managing critical exposures. For critical vulnerabilities specifically, exploits appeared before scanner detection became available in 62.5% of cases at Tenable, 64.5% at Qualys, and 73.5% at Rapid7. In other words, even the fastest-responding platform delivered signatures after exploit code was publicly available for nearly two-thirds of the most severe vulnerabilities.

The variance across vendors is significant for organizations that have standardized on a single platform, but the broader pattern holds across all three: scanner-based detection, regardless of vendor, now functions as a lagging indicator for critical CVE response. The infrastructure that security teams rely on to identify what needs patching cannot reliably deliver that information before adversaries begin exploitation.

This does not mean vulnerability scanners have lost operational value. They remain essential for validating remediation across large asset inventories, confirming patch deployment, and surfacing lower-severity exposures that would otherwise go unaddressed. The issue is one of sequencing and timing: for the subset of vulnerabilities that drive emergency patching decisions and incident response mobilization, scanner output arrives too late to serve as the primary intelligence source.

The Architectural Change Required to Overcome the Detection Challenge

The data from our research suggests an architectural shift towards a new way of constructing vulnerability detection pipelines in enterprise environments. Whereas in the past, scanner visibility was considered to be the first and the most fundamental layer for detecting vulnerabilities, the role of scanners becomes increasingly secondary, playing the part of coverage verification and validation.

Organizations that have begun adapting their workflows are layering threat intelligence feeds, exploit database monitoring, and patch diff analysis into their vulnerability management pipelines ahead of scanner-based detection. That architectural shift treats CVE publication (not scanner signature availability) as the trigger for triage and impact assessment. Security teams that make this transition evaluate patch applicability and exposure risk using asset inventory, software bill of materials (SBOM) data, and configuration management databases rather than waiting for a scanner to confirm the presence of a vulnerable component.

The competitive landscape includes vulnerability intelligence platforms such as VulnCheck and Nucleus Security, which aggregate exploit availability data, CISA Known Exploited Vulnerabilities (KEV) catalog updates, and vendor patch metadata to provide earlier warning than signature-based scanning alone. Runtime detection and behavioral monitoring tools (including endpoint detection and response platforms from CrowdStrike, SentinelOne, and Microsoft Defender for Endpoint) offer an alternative detection model that does not depend on vulnerability signatures, instead identifying exploitation attempts based on process behavior, memory manipulation, or privilege escalation patterns.

These approaches do not replace vulnerability scanning. They create a layered architecture in which scanner-based detection validates and extends coverage rather than initiating response. For organizations still dependent on scanner output as the sole input to vulnerability prioritization, the 83.2% visibility gap identified in the research represents a structural risk that process optimization alone cannot remediate.

Budget and Procurement Signals Emerging from the Detection Gap

The widening gap between exploit availability and scanner signature release creates immediate demand for tooling that provides sub-24-hour visibility into newly disclosed vulnerabilities. That demand manifests in several budget areas.

Threat intelligence platforms that deliver exploit availability tracking, weaponization timelines, and proof-of-concept code monitoring as a service are becoming table-stakes subscriptions for security operations centers (SOCs) managing critical infrastructure. Organizations that previously treated threat intelligence as optional context are reclassifying it as a required input to vulnerability triage.

Attack surface management platforms that continuously map internet-exposed assets and correlate them against CVE disclosures in near real-time are gaining traction as an alternative to waiting for internal scanners to complete scheduled scans. These platforms (offered by vendors including Censys, Shodan, and Randori, which was acquired by IBM) provide external validation of exposure before internal detection infrastructure updates.

SBOM and asset inventory tooling that enables security teams to answer “do we run this software?” within minutes of a CVE disclosure is shifting from a compliance checkbox to an operational necessity. Organizations that lack accurate, query-able software inventories cannot perform rapid exposure assessments without waiting for scanner-based confirmation.

The budget conversation is shifting from “how do we scan faster?” to “how do we know what we’re exposed to before the scanner tells us?” That reframing drives investment toward discovery, inventory, and intelligence aggregation rather than incremental improvements to signature delivery speed.

Organizations With Continuous Internet Exposure Face the Shortest Runway

The urgency described in the research is not uniformly distributed. Organizations operating continuous internet-facing services (particularly in financial services, healthcare, telecommunications, and SaaS delivery) face the most compressed response windows. For these environments, a 12-hour detection lag is not a planning problem; it is an active exposure during which exploitation can proceed undetected.

Regulated entities subject to breach notification requirements under GDPR Article 33, HIPAA breach notification rules at 45 CFR §164.404, or state-level data breach statutes face compounding pressure: the same detection gap that delays awareness of vulnerable assets also delays the clock on breach detection and mandatory reporting timelines. If exploitation occurs during the window before scanner-based detection becomes available, the organization may not discover the compromise until forensic investigation weeks later, at which point regulatory reporting deadlines have already passed.

Cloud-native organizations running microservices architectures and containerized workloads face a distinct challenge: traditional scanner-based models depend on persistent, inventory-able infrastructure, but ephemeral compute instances and auto-scaled container groups may spin up, become exploited, and terminate before a scheduled vulnerability scan completes. For these environments, runtime detection and policy-based admission controls are not optional enhancements. They are the only detection layer capable of operating at the pace the infrastructure requires.

The organizations with the least time to act are those that have not yet decoupled vulnerability detection from scanner signature availability. If your security program still treats scanner output as the authoritative source of truth for what is vulnerable, the 83.2% visibility gap identified in this research applies directly to your exposure posture. The question is not whether to adapt the architecture. It is whether that adaptation occurs as a planned investment or as an emergency remediation following exploitation during a detection gap you did not know existed.