From CVE to RCE in Hours: The Collapse of the Exploitation Window

A critical vulnerability drops at 9 AM. By 1 PM, attackers are actively scanning for unpatched systems. By 5 PM, the first victims are compromised. By the time your patch management team processes the ticket on Monday morning, hundreds of organizations have already been breached.

This isn’t a worst-case scenario. It’s a Tuesday in 2025.

TL;DR

The time from CVE disclosure to active exploitation has collapsed from 756 days (2018) to hours (2024–2025)

28% of exploits are launched within 1 day of public disclosure

29% of exploited CVEs were attacked on or before the day the CVE was published — meaning before any patch existed

Adversary lateral movement (breakout time) averages 29 minutes after initial access

Monthly patching cycles and CVSS-only prioritization are dangerously inadequate

Defenders need exploitation intelligence, not just vulnerability scores

The Old Assumption That’s Getting Organizations Breached

For years, the security industry operated on a comfortable assumption: attackers need time to develop exploits after a vulnerability is disclosed. You have weeks — maybe a month — to test and deploy patches before real-world exploitation begins.

That assumption was never perfectly safe. But it was close enough to build patch management programs around.

It is now completely wrong.

The exploitation window — the time between a vulnerability being publicly known and attackers weaponizing it — has collapsed to the point where “patch before exploitation” is often mathematically impossible.

The Data: A Decade of Acceleration

The numbers tell a stark story:

Year	Average time from disclosure to exploitation
2018	756 days
2021	84 days
2023	6 days
2024	~4 hours (fastest observed)
2025	Often before disclosure (zero-day)

This isn’t a gradual decline — it’s a cliff edge. The entire concept of a meaningful “patch window” has been erased.

By the numbers for 2025

28% of exploits in 2025 were launched within 1 day of disclosure
55% of zero-days were exploited within one week of public disclosure
28.96% of Known Exploited Vulnerabilities were exploited on or before the day their CVE was published — up from 23.6% in 2024
67.2% of exploited CVEs in 2026 are zero-days, compared to just 16.1% in 2018
Vendors take an average of 15 days to patch actively exploited vulnerabilities

The gap between “exploit exists in the wild” and “patch available” is now measured in weeks — in the attacker’s favor.

What Happens After Initial Access: 29 Minutes to Lateral Movement

Getting into the network is just the first step. What happens next is equally alarming.

CrowdStrike’s 2026 Global Threat Report puts the average eCrime breakout time — the time from initial compromise to lateral movement to other systems — at 29 minutes.

Mandiant’s M-Trends 2026 report adds another data point that should concern every SOC analyst: adversary hand-off time (the time between one attacker establishing access and passing it to another, often in ransomware-as-a-service operations) has collapsed to 22 seconds.

To put that in perspective: your SOC analyst might need 15–20 minutes just to investigate and triage an alert. By then, the attacker is already moving through your network.

The math is unforgiving. If you can’t detect and respond in under 29 minutes, you’re likely dealing with a lateral movement incident, not just an initial compromise.

Why Exploitation Has Accelerated So Dramatically

Bug bounty programs create a race

When a researcher finds a vulnerability, the clock starts immediately. The moment a CVE is assigned and a patch is announced, the race begins: defenders race to deploy the patch, attackers race to reverse-engineer it and build an exploit.

Attackers can diff the patch, identify the vulnerable code path, and build a working exploit in hours. This is a well-documented technique called patch diffing. In 2025, AI-assisted analysis has made it faster.

AI is industrializing exploit development

In 2025, AI agents generated over 40 working exploits for a single vulnerability for $50. A separate experiment showed that AI agent swarms found 100+ exploitable vulnerabilities across major manufacturers for $4 per bug.

Exploit development — once requiring specialized skills and significant time — is becoming automated at scale. The barrier to entry for exploitation is dropping every month.

Edge devices and internet-facing services are easy targets

Network edge devices — VPNs, firewalls, remote access gateways — are uniquely attractive targets. They sit directly on the internet, they often can’t be easily patched without taking services down, and they process authentication traffic, making them valuable for credential harvesting.

CVE-2025-10585 (Chrome V8) was actively exploited within 24 hours. CVE-2026-35616 (Fortinet FortiClient EMS) was weaponized almost immediately after disclosure. CVE-2025-8110 (Gogs RCE) was exploited before many administrators even knew the software existed in their environment.

The pattern is consistent: disclose, scan, exploit, in that order — compressed to hours.

Why Traditional Patch Management Fails Here

Traditional vulnerability management works roughly like this:

Scanner runs weekly or monthly
Vulnerabilities are identified and scored with CVSS
High/Critical findings are assigned to teams
Patches are tested, approved, and deployed on a defined cycle

This process is designed for a world where you have 30 days. In a world where exploitation happens in hours, it’s a structured way to be perpetually behind.

The CVSS problem

CVSS (Common Vulnerability Scoring System) measures theoretical severity — how bad could this vulnerability be in a worst-case scenario? It does not measure whether anyone is actually exploiting it right now.

A CVSS 9.8 vulnerability that no attacker has ever touched is less dangerous today than a CVSS 6.0 vulnerability being actively mass-exploited. But most organizations still prioritize by CVSS score alone.

This is the wrong signal. You need to prioritize based on exploitation evidence, not theoretical severity.

What Defenders Must Do Differently

1. Separate your patch workflows by exploitation status

Create two distinct tracks:

Track A — Actively exploited (KEV-listed)

SLA: 24–48 hours for internet-facing assets
Process: emergency change, expedited testing, immediate deployment
Scope: anything public-facing, anything processing authentication

Track B — Not yet exploited

SLA: standard cycle (1–4 weeks depending on severity)
Normal testing and change management

The key input: CISA’s Known Exploited Vulnerabilities (KEV) catalog. This is authoritative, free, and updated daily. Any CVE on this list is being exploited in the wild right now. Subscribe to change notifications.

Additional signals worth following: VulnCheck, Mandiant threat intel, Shadowserver foundation alerts.

2. Monitor for exploitation patterns, not just patch status

By the time exploitation starts, patching may no longer be sufficient for assets that were already exposed. You need to know if you were compromised in the window between disclosure and patch deployment.

For each critical CVE on internet-facing systems, ask: was this system exploited before we patched it?

Detection signatures for common exploitation patterns:

Web server process spawning unexpected child processes (httpd spawning bash, IIS spawning cmd.exe)
Unexpected outbound connections from services that shouldn’t initiate outbound traffic
Authentication anomalies on VPN/remote access infrastructure
New scheduled tasks or services created shortly after patch disclosure date

3. Treat your attack surface inventory as a real-time asset

You cannot respond to exploitation in 24 hours if you don’t know which systems are running vulnerable software. Maintain a live inventory of internet-facing assets with version information.

Basic approach:

# Continuously scan your own IP ranges
# This is what attackers run against you within hours of a disclosure

nuclei -l targets.txt -t cves/ -severity critical,high -o findings.txt

Internal tools: your CMDB, cloud provider asset inventories, network scanners. External perspective: Shodan, Censys, your ASM platform.

4. Build detection before exploitation starts

When a high-severity CVE drops for a product you run, don’t just queue up a patch ticket — also write a detection rule.

What does exploitation of this vulnerability look like in logs? What network traffic would it generate? What process would it spawn? Security teams that answer these questions before exploitation begins are dramatically better positioned.

Check threat intelligence sharing communities: Sigma rules, public GitHub repositories, vendor threat research blogs. Many exploit patterns are published within hours of CVE disclosure by the community.

5. Run exploitation simulations

Monthly or quarterly, pick a recent high-severity CVE for a product in your environment. Ask: how long would it have taken us to:

Detect we had vulnerable systems?
Deploy a patch (or mitigation)?
Detect active exploitation?

This exercise reveals real gaps in your process — before an attacker reveals them for you.

The 22-Second Adversary

Mandiant’s finding that adversary hand-off takes 22 seconds deserves specific attention. It means that in ransomware-as-a-service operations, the initial access broker (who exploits the vulnerability) hands access to the ransomware operator in less time than it takes to read this sentence.

This is an assembly line. The people who find and exploit vulnerabilities have nothing to do with the people who install ransomware. They’re separate teams, with separate tools, communicating through automated infrastructure.

And it works faster than most security teams can even receive an alert.

The implication: you need automated, real-time detection and response, not manual investigation workflows, for initial exploitation events on internet-facing infrastructure.

What You Can Do Today

Immediate (this week):

Subscribe to CISA KEV updates — cisa.gov/known-exploited-vulnerabilities-catalog
Identify your five most critical internet-facing services (VPN, remote access, public web apps)
Confirm current patch status for all critical/actively-exploited CVEs affecting those services

Short-term (this month):

Establish a 24–48 hour SLA for KEV-listed CVEs on internet-facing assets
Build one detection rule for the most recent critical CVE affecting your stack
Run a tabletop: “A CVE drops today for our VPN gateway. Walk through what happens in the next 48 hours.”

Ongoing:

Add VulnCheck or equivalent threat-intel feed to your vulnerability management process
Build an attack surface inventory that includes software versions
Review your detection coverage for “exploitation of public-facing application” as an initial access technique

Vulnerability Exploitation Overtook Phishing — What That Means for Defenders — The broader context: why exploits are now the #1 initial access vector
Why Enterprise VPN Gateways Are Always Vulnerable — Deep dive on the most-targeted category of internet-facing devices
LOLBins: Living off the Land on Windows — What attackers do after exploitation, without touching malware
DFIR: Incident Response Complete Guide 2026 — The playbook for when exploitation succeeds