In 2020, attackers took 700+ days to exploit a published CVE. In 2025, that number hit 44. What changed, and what defenders need to do differently.

In 2020, if a CVE dropped on Monday, your security team had roughly two years before an attacker would figure out how to weaponize it reliably in the wild. You had time to patch. Time to prioritize. Time to deprioritize the wrong things.

That number is now 44 days.

Not 700. Not 200. Forty-four.

And it's still falling.

What actually changed

The metric is called time-to-exploit: the number of days between a vulnerability being publicly disclosed and a working exploit appearing in real-world attacks.

For most of the 2010s, that window was measured in months to years. Exploit development required deep technical skill, manual reverse engineering, and a lot of time. Not many people could do it.

Then AI-assisted coding crossed a threshold.

In late 2024 and through 2025, frontier models hit an inflection point on software development benchmarks. In August 2024, top models could resolve roughly a third of real GitHub issues autonomously. By December 2025, that number was approaching 81%. The same capability that makes coding faster for defenders makes exploit development faster for attackers.

A 17-year-old in Osaka extracted personal data from 7 million users of Japan's largest internet café chain using AI tools. When asked why, he said he wanted to buy Pokémon cards. He wasn't technical. He didn't need to be.

Three teenagers — ages 14, 15, and 16 — used ChatGPT to hammer a mobile carrier's systems 220,000 times. No coding background. The AI wrote the tool.

This is what the collapse of technical barriers looks like from the defender's side.

The remediation gap that's widening

Here's the math that should keep every CISO up at night:

Attackers are moving from disclosure to exploit in 44 days.

The average time to remediate a known high- or critical-severity CVE in enterprise environments is 74 days.

The window to patch has become a window of exposure. You're guaranteed to be vulnerable during that gap, and the gap is almost certainly getting exploited.

This isn't a new problem — it's an old problem that's gotten dramatically worse. The traditional vulnerability management model (scan, triage, ticket, patch) was designed for a world where attackers needed months. It's fundamentally broken for a world where they need weeks.

What AI-assisted exploitation actually looks like

For pentesters, this is both a capability upgrade and a threat intelligence signal.

On the offensive side, AI can now:

  • Analyze a CVE disclosure and automatically generate a proof-of-concept in hours, not weeks
  • Fuzz API endpoints and adapt attack payloads based on responses
  • Analyze binary patches to identify the vulnerability that was fixed (reverse-patch analysis)
  • Write custom shellcode and evasion techniques based on target environment context

The sophistication floor for attackers has dropped to nearly zero. The ceiling hasn't changed — nation-state groups are still ahead — but the middle tier has expanded massively.

In 2022, there were 55,000 malicious packages in public code repositories. By 2025, that number exceeded 454,000. That's not a coincidence with the AI coding timeline.

What this means for your pentest methodology

If you're doing pentests with a scope that includes anything running public-facing CVEs, your window for the "you should patch this" recommendation has collapsed.

A few things that need to change in practice:

Exploit freshness matters more. If you're using Metasploit modules from 2022 on a 2025 engagement, you're testing with a blunted knife. The attacker community has moved past those. Use recent PoCs or build custom ones.

Patch lag is now a primary finding, not a housekeeping note. If a client has a critical CVE unpatched for 45 days, that's not a "medium — remediate within 90 days" item. That's a breach that may already be in progress.

Continuous testing is no longer optional. Point-in-time pentests made sense when the threat landscape changed quarterly. When a new exploit can appear in 44 days, a once-a-year pentest is a compliance checkbox, not a security control.

The defensive response

Mature security teams are adjusting to this reality in a few concrete ways:

EPSS over CVSS. The Exploit Prediction Scoring System gives you a probability that a vulnerability will be exploited in the wild in the next 30 days. This is more actionable than a theoretical severity score. Prioritize by EPSS when the queue is longer than your team can handle.

Patch SLAs tied to actual exploit timelines. "30 days for critical" was written when time-to-exploit was 700 days. In 2026, a 30-day SLA for critical CVEs means you're still exposed for the entire window between disclosure and live exploitation. Mature teams are moving to 7-day SLAs for criticals where EPSS signals active exploitation probability.

Automated patch testing pipelines. The bottleneck is usually "we need to test the patch before we deploy it." Automating staging environment validation removes human lag from the process.

Threat intelligence integration. Know which CVEs in your environment have public PoC code. Tools like Greynoise, VulnCheck, and CISA KEV let you filter for "actively exploited in the wild" rather than guessing.

The 44-day number will keep falling. The patching window will keep shrinking. The organizations that survive the next five years of this aren't the ones with the best patch management policy — they're the ones who've restructured their entire remediation workflow around the reality that the attacker is now almost always moving faster.

Speed is the new sophistication.