When Palo Alto Networks’ Unit 42 team published its 2024 Incident Response Report, one number stood out: attackers were exploiting newly disclosed software flaws in a median time of roughly 10 hours. Just two years earlier, Mandiant’s M-Trends 2023 report and earlier Unit 42 data placed that figure in the range of several days. The compression has continued into mid-2026, and it is reshaping how security teams, federal agencies, and software vendors think about the race between patching and exploitation.
The data behind the shrinking window
The most authoritative public record of real-world exploitation is the Known Exploited Vulnerabilities (KEV) Catalog maintained by the Cybersecurity and Infrastructure Security Agency. CISA built the catalog as a binding directive for federal civilian agencies: once a vulnerability is listed, those agencies must remediate it within a set deadline. Private-sector security teams have widely adopted it as a prioritization baseline. By early 2025, the catalog contained more than 1,100 entries, and the pace of additions has accelerated year over year.
CISA’s catalog confirms that exploitation happened but does not calculate how quickly it started. That timing math comes from vendors like Palo Alto Networks, Mandiant, and Rapid7, which compare the date a CVE is published against the earliest confirmed exploitation activity. Their analyses consistently show the gap collapsing. Palo Alto’s Unit 42 data pegged the median at about 10 hours in its 2024 report. Rapid7’s annual vulnerability intelligence reports have documented a parallel trend, noting that attackers increasingly exploit flaws on the same day proof-of-concept code appears on platforms like GitHub.
“We are seeing threat actors operationalize exploits within hours of a CVE being published, not days,” said Matt Kraning, chief technology officer of Cortex at Palo Alto Networks, summarizing the Unit 42 findings. That assessment is echoed across the industry. “The time-to-exploit for critical vulnerabilities has compressed dramatically,” noted Caitlin Condon, head of vulnerability research at Rapid7, in the company’s 2024 Attack Intelligence Report. “Defenders who still operate on a monthly patch cadence are bringing a calendar to a stopwatch fight.”
Readers should note an important caveat: these vendor averages reflect editorial choices about which vulnerabilities to include, how to define the start and end of the exploitation window, and how to handle outliers. One vendor may count the first observed scan as exploitation; another may require a confirmed compromise. Those definitional differences can shift the average by hours. The 10-hour figure is best understood as an informed estimate anchored in large incident-response datasets, not a single official measurement from any government body.
Real-world examples anchor the trend
The pattern is not abstract. When the critical Log4Shell vulnerability (CVE-2021-44228) was disclosed in December 2021, mass scanning and exploitation attempts began within hours, eventually affecting hundreds of thousands of systems worldwide. More recently, the MOVEit Transfer vulnerability (CVE-2023-34362) was weaponized by the Cl0p ransomware group so quickly that many organizations were breached before patches could be applied, ultimately compromising data from more than 2,500 organizations. These cases illustrate the concrete consequences when exploitation outpaces remediation.
Academic evidence backs the pattern
Independent research supports the vendor findings. A preprint paper hosted on arXiv, produced through Cornell University‘s computer science pipeline, describes an internet-scale study of a vulnerability the authors call React2Shell. Using a network telescope that captures scanning traffic across large swaths of IP address space, the researchers measured a surge in exploitation attempts within hours of the flaw’s public disclosure.
The telescope approach is significant because it records actual probes hitting real IP addresses rather than relying on surveys or vendor telemetry. That gives the data a different evidentiary weight than a marketing-driven threat report. The paper has not yet completed formal peer review, and the vulnerability name “React2Shell” is the authors’ own label rather than a widely recognized identifier, so readers should treat the findings as preliminary. Its methodology is reproducible, however, and its findings align with what incident responders have been reporting from the field.
A single vulnerability study cannot, on its own, validate a cross-category average. Different flaw types attract different attacker populations. A remote code execution bug in a widely deployed web framework will draw faster exploitation than a local privilege escalation issue in niche industrial software. But the React2Shell data adds a concrete, independently measured data point to a body of evidence that all points in the same direction: hours, not days.
What is still uncertain
Several gaps remain. No single longitudinal study has tracked the same population of vulnerabilities over multiple years using consistent methods. The narrative of acceleration rests on comparing different vendor reports from different periods, each with its own criteria. That comparison is suggestive, but it is not the same as a controlled before-and-after measurement.
The causes of the speed increase are also debated. Security researchers have pointed to the growing availability of automated exploit kits, the rapid publication of proof-of-concept code on GitHub, and the potential role of AI-assisted code generation. Microsoft and Google’s Mandiant have both publicly acknowledged that threat actors are experimenting with large language models for offensive purposes. But no peer-reviewed study has isolated any single factor as the primary driver. Correlation between faster exploitation and the rise of automation tools is plausible; a proven causal link is a different matter.
Detection lag adds another layer of uncertainty. Both CISA’s catalog entries and academic measurements depend on when exploitation is noticed, not necessarily when it begins. Sensors can miss the earliest probes, and incident responders may take hours or days to confirm activity. A vulnerability quietly exploited for weeks before discovery could appear, in hindsight, as if exploitation started only when defenders finally spotted it. Any average built on observed first activity is therefore a lower bound on attacker speed, not a precise stopwatch reading.
How defenders can close the gap before the next critical CVE drops
For organizations trying to act on this information in May and June 2026, the practical takeaway does not hinge on whether the exact median is 10 hours or 14 hours. The directional signal from CISA’s expanding catalog, vendor incident data, and academic measurement is consistent: the window between a vulnerability becoming public and the first exploitation attempts is now measured in hours. Patch management processes built around weekly or monthly cycles are increasingly mismatched with that reality, especially for internet-facing systems and high-severity flaws.
Several concrete steps can close the gap:
- Tighten internal SLAs for critical patches. If your current target is “within 30 days,” a vulnerability in a public-facing web server may be exploited thousands of times before your team even schedules the update.
- Pre-test updates for commonly used platforms. Maintaining a staging environment that mirrors production lets teams validate patches within hours of release rather than waiting for a scheduled maintenance window.
- Automate the deployment pipeline. Just as attackers use scripts and bots to weaponize flaws at scale, defenders need automated asset inventory, configuration management, and rollback mechanisms to push fixes quickly without introducing instability.
- Assume exploitation is already underway. Incident response plans should treat a widely publicized critical CVE as an active threat from the moment it hits the news, not as a future risk to be triaged next week.
The evidence base around weaponization speed is still maturing. Primary datasets confirm that exploitation follows disclosure very quickly in high-profile cases, and vendor analyses suggest the pattern is widespread. Methodological gaps, inconsistent definitions, and detection delays mean any single numeric average should be treated as an informed estimate. But the conclusion that matters for mid-2026 is not in dispute: the window for patching exposed systems before attackers arrive has narrowed to the point where hours count, and security programs that have not adapted are increasingly responding to breaches instead of preventing them.
More from Morning Overview
*This article was researched with the help of AI, with human editors creating the final content.
