Time to patch is moving toward seconds because time to exploit already has. Mandiant puts the average exploit at seven days before the patch. Verizon puts the median fix at 43 days. Closing that gap means shipping fixes to production right away, proving them live, and watching that they hold.
Attackers used to need weeks to turn a bug into a working exploit. Now they need hours, and they often start before the bug is public. Patching has not kept up. Most teams still measure time to fix in weeks.
This post covers the data behind that gap. Then it explains why opening a pull request is no longer the finish line, and what we are building at MindFort to close it.
How fast are attackers exploiting vulnerabilities now?
Faster than defenders can read the advisory. Mandiant found the average time to exploit was 63 days in 2018–19. It fell to 32 days in 2021–22 and five days in 2023 (Mandiant ). Its M-Trends 2026 report puts it at seven days before a patch is released (Mandiant ).
AI is speeding this up. In June, Anthropic tested its models on 18 recent Firefox patches. Its strongest model wrote its first working exploit in just under an hour, using only the public patch (Anthropic ). In October, an unreleased Anthropic model wrote a remote root exploit for a Linux kernel bug in about 53 minutes (Anthropic ). The bug was fixed upstream, but Ubuntu and Red Hat still had no fixed kernel for some releases weeks later (BleepingComputer ).
The field shows the same thing. On August 31, an attacker used hundreds of AI agents against PaperCut print-management servers. They went from an empty workspace to their first real break-in in under four hours. Once the campaign launched, 11 organizations fell in 26 seconds. GreyNoise counted 395 victim organizations in 48 countries (GreyNoise ).
How long does it take teams to patch?
Weeks to months. Verizon's 2026 Data Breach Investigations Report found the median time to fully fix a known-exploited vulnerability was 43 days, up from 32 the year before. Only 26% of those vulnerabilities were fully fixed, down from 38% (Verizon ). That same year, exploiting a vulnerability became the top way breaches start.
Other datasets agree. Edgescan puts the average fix time for high and critical app and API flaws at 55 days (Edgescan ). Synack customers averaged 38 days in 2025, and that was after cutting their fix time nearly in half (Help Net Security ).
Attackers move in days. Fixes take weeks to months.
Days, 2025. Exploited: Rapid7's median time from CVE publication to the CISA KEV list. Patched: Synack (mean fix time), Verizon DBIR 2026 (median full fix of known-exploited bugs), and Edgescan (mean fix time, high and critical app and API flaws). Each uses its own dataset, so read them as orders of magnitude.
The averages also hide a long tail. Qualys tracked more than a billion remediation records for critical CISA KEV bugs in 2025. At disclosure, 85% of vulnerable assets were unpatched. A week later, 63% still were. At 90 days, 12% were still open (Qualys ).
Share of vulnerable assets still unpatched after disclosure
Critical CISA KEV vulnerabilities, 2025. Day 21 is roughly the average remediation mark. Source: Qualys TRU, The Broken Physics of Remediation.
Qualys found that 88% of the 52 high-profile exploited bugs it tracked were fixed slower than they were exploited. Half were exploited before they were disclosed.
Why isn't finding vulnerabilities faster enough?
Because finding was never the slow part. AI tools now find bugs faster than teams can fix them. Verizon found the median organization had 50% more known-exploited bugs to patch in 2025 than the year before. Fix rates went down, not up.
Exploitation is moving just as fast. Rapid7 found the median time from a bug's publication to the CISA KEV list fell from 8.5 days to five days in 2025 (Rapid7 ).
More findings without faster fixes just makes the backlog bigger. The number that matters is how long an exploitable bug stays open in production.
Why is opening a pull request no longer enough?
A pull request is not a fix. It is a fix waiting in line. Today, a lot of "automated remediation" stops at the PR. Then the patch sits behind code review, a release train, and a change window. The clock keeps running the whole time.
Here is where time goes in a typical fix:
| Step | Typical wait today | Why it stalls |
|---|---|---|
| Find and validate | Hours to days | Scanner noise and manual triage |
| Write the patch | Days to weeks | Competes with the roadmap |
| Review and merge | Days | Reviewers lack security context |
| Deploy to production | Days to weeks | Release trains and change windows |
| Verify the fix | Weeks, or never | Waits for the next scan or pentest |
Each step adds days. Attackers now need hours. Shaving a day off one step does not change the math. The whole loop has to run at machine speed.
What does patching at machine speed look like?
It runs the full loop, not just the first half. We think about it in four stages.
- Prove it. Exploit the finding to show it is real and reachable. This keeps false alarms from eating your fix budget.
- Patch to production. Write a small, scoped fix and ship it through your own pipeline, tests, and guardrails. Low-risk fixes can ship on their own. Riskier ones wait for a human to approve.
- Validate live. Re-run the original exploit against production right after deploy. A green build is not proof. A failed exploit is.
- Monitor that it holds. Keep retesting. New code, config drift, or a rollback can reopen the same hole. If it reopens, catch it in minutes, not at next year's pentest.
This is a shift in what "done" means. Done used to mean a merged PR. Now it means the exploit fails in production, and keeps failing.
Isn't auto-patching to production risky?
It can be. In July 2024, one faulty CrowdStrike update crashed about 8.5 million Windows machines (Microsoft ). Ship fixes fast without guardrails and you trade attacks for outages you caused yourself.
That is why the last two stages matter as much as the first two. Fast patching is only safe when each fix is:
- Small. Change the vulnerable code path, not the whole service.
- Proven. Retest the exploit and run your existing tests before and after deploy.
- Reversible. Ship behind your normal rollout and rollback controls.
- Watched. Monitor errors and behavior after deploy, and roll back fast if needed.
- Governed. Let your team set which fixes can ship on their own.
Some systems can't be patched quickly at all, like old devices and industrial controllers. Those need isolation and network controls instead. But for web apps, APIs, and cloud config, the fix is usually yours to ship. That is where machine-speed patching works today.
How does MindFort move time to patch toward seconds?
MindFort already runs most of this loop. Our agents continuously pen test your apps, APIs, and infrastructure. They prove each finding with a working exploit, so false positives stay under 1%. Then they write the code patch or cloud config fix and open a pull request. Once it merges, they retest to confirm the hole is closed. We call this Autonomous Exploitation and Remediation (AXR).
Now we are building past the pull request. Our focus is the last mile:
- Policy-driven deploys. Fixes that meet your rules ship through your own CI/CD to production. The rest go to a human with full context.
- Live validation. Agents replay the exploit against production as soon as the patch lands, and attach the proof.
- Continuous regression checks. Agents keep retesting fixed findings, so a hole that reopens gets caught right away.
- Reliable, reversible fixes. Smaller patches, stronger checks before and after deploy, and fast rollback when something looks wrong.
The goal is simple. Time to patch should be measured by how fast an exploit stops working in production. Attackers already work in seconds. Fixes need to as well.
If you want to see how fast your own fixes can move, book a demo . For more on why the testing side has to run continuously, read Why Are Agent Swarms the Future of Security? and How Often Should You Pen Test?.
FAQ
What is time to patch?
Time to patch is how long a vulnerability stays open in production after it is found or disclosed. It is often tracked as mean time to remediate (MTTR). It ends when the fix is live and the bug can no longer be exploited, not when a ticket or pull request is opened.
How fast are vulnerabilities exploited in 2026?
Faster than ever. Mandiant's M-Trends 2026 report puts the average time to exploit at seven days before a patch is released. Rapid7 found the median time from publication to the CISA KEV list fell to five days in 2025. AI models now turn a published patch into a working exploit in under an hour.
Is auto-patching to production safe?
It is safe when the patch is small, tested, and easy to roll back. That is why every fix needs a live retest and monitoring after deploy. Teams should set policy on which fixes can ship on their own and which need a human to approve.
Does MindFort patch vulnerabilities automatically?
Yes. MindFort agents prove each finding with a working exploit, then write the code patch or cloud config fix. They open a pull request and retest to confirm the hole is closed. We are now building the systems to take those fixes all the way to production and keep watching them.
About the author
Akul Gupta
Co-Founder & CTO · MindFort
AI researcher focusing on LLMs in cybersecurity. Red-teamed models for OpenAI and Anthropic as part of their safety programs. Published multiple conference papers. M.S. Computer Science, UIUC.