AI Can Speed Up Exploits. The Patch Still Has to Reach the Machine.
An a16z editorial warns that cheaper attacks could reach more small organizations. The underlying reports show why exploit speed, patch release and completed remediation must be measured separately.

The actual story.
A security update can be available while the machine it protects remains vulnerable. That interval is the problem behind a16z’s “The Exploit Was the Bottleneck,” by Asaf Ezra and Steph Zhang, published November 5. Their argument: AI is reducing the work needed to turn software flaws into attacks faster than many organizations can roll out fixes.
The authors expect repeated outbreaks to hurt hospitals, schools and small infrastructure operators that cannot update quickly. That is a forecast, not a measured outcome of AI. The evidence is clearest when three different clocks are kept separate: exploit development, observed exploitation and organizational remediation.
Clock one: building the exploit
An exploit turns a software weakness into an action an attacker can use. RAND’s 2017 study of zero-day vulnerabilities found a median of 22 days to develop a functioning exploit after an exploitable vulnerability was identified.
In Anthropic’s June 2026 N-day experiments, Mythos Preview produced its first working Firefox exploit in just under an hour and eight over roughly 12 hours. These were vendor-run experiments involving selected, already patched vulnerabilities. They were not a measurement of the average criminal operation, nor a like-for-like repeat of RAND’s study. The comparison illustrates capability gains; it does not establish a universal “one month becomes one hour” conversion.
Clock two: when attacks are observed
Mandiant’s historical analysis reports average time to exploit of 63 days in 2018–19. Its definition on that page measures exploitation before or after patch release. M-Trends 2026 puts the 2025 estimate at minus seven days: exploitation preceded the patch on average.
That wording matters. Public disclosure and patch release are different milestones, even when they happen together. Nor does a negative average mean every flaw is exploited before anyone can fix it. These are observations of exploited vulnerabilities, not a countdown applying to every published bug.
The timing data also cannot tell us how much of the change AI caused. Mandiant says the vast majority of successful 2025 intrusions still arose from human and systemic failures, and does not characterize that year’s breaches as directly caused by AI. Faster observed exploitation and stronger AI tools are related concerns, but one statistic does not prove the other caused it.
Clock three: getting every affected system fixed
Verizon’s 2026 Data Breach Investigations Report executive summary reports a median of 43 days for full resolution of vulnerabilities in the CISA Known Exploited Vulnerabilities catalog, up from 32 days. In its data, organizations fully remediated only 26% of those vulnerabilities in 2025, down from 38% the previous year.
This measures organizational remediation. It is not how long a software vendor took to write or publish a patch. An available update still has to reach the affected systems. Comparing Verizon’s median with Mandiant’s mean can highlight the mismatch, but subtracting them would not produce a valid universal attack window: the populations and measures differ.
Why a small target can still matter
Ezra and Zhang’s concern is economic as much as technical: cheaper automated work could make smaller organizations worth attacking. They forecast an extended period of damaging outbreaks rather than the collapse of the internet. Their practical distinction is between systems that can update readily and those whose updates interrupt essential services.
For readers responsible for a business, the useful question is therefore more specific than “Did the vendor fix it?” Ask which affected systems are still exposed, who owns the work, and what protection is in place until remediation is complete. A patch announcement is the start of that check, not evidence that it has finished.
“A patch exists” and “our systems are fixed” are different answers. Ask for the remaining exposed systems, the person responsible and the protection in place while updates are applied. Faster exploit development makes that unfinished work more consequential.
Receipts, not rumors.
- Mandiant · historical time-to-exploit definition
- Mandiant · M-Trends 2026
- Verizon · 2026 DBIR executive summary
- RAND · Zero Days, Thousands of Nights
- Anthropic · N-day exploit experiments
Read the original reporting: a16z · Asaf Ezra and Steph Zhang
The reporting above provides context. Illustrations are editorial interpretations, not source photographs.

What’s your take?