How AI Collapsed the Exploit Window from 745 Days to 44

In a controlled two-week window earlier this year, Anthropic’s Claude Opus 4.6 model was turned loose on Firefox in a collaboration with Mozilla. It found 22 vulnerabilities. Mozilla classified 14 of them as high severity.

Sit with that for a moment. The point is not the research partnership. It is the asymmetry it exposes. An AI model, working inside a defined evaluation window, surfaced that many flaws in days. Attackers running equivalent tooling do not stop the clock when your scheduled patch window opens.

For years, patching followed a comfortable rhythm. A vulnerability was disclosed, a patch was released, and your IT team applied it within a week or so. That rhythm assumed the exploit arrived after the fix. Increasingly, it arrives first.

UK organisations face this on two fronts: the threat is faster, and the guidance has already moved. National Cyber Security Centre (NCSC) expectations assume a compressed environment, yet many businesses still run the slow-cycle processes that guidance has quietly left behind.

Here is what you will come away knowing: what the real exploit timeline looks like now, exactly what NCSC guidance demands when a flaw is being actively exploited, and the specific questions to put to your managed service provider before the next critical advisory drops into your inbox.

Why AI has made the old patching schedule obsolete

A patch cycle measured in weeks feels reasonable. It gives your team time to test, to schedule downtime, to avoid breaking production. For most of the last decade, it was reasonable. The data says that era is over.

The average time-to-exploit has collapsed from roughly 745 days in 2020 to about 44 days in 2025, according to multi-year trend analysis flagged as indicative. That is a 94% compression in five years. Narrower windows tell a sharper story: the mean time to exploit a disclosed vulnerability fell from around 32 days in 2022 to about 5 days for 2023 exploitation activity.

The deeper problem is not that patching got slower. It is that exploitation now routinely arrives before any patch exists. When the attack precedes the fix, a patch-on-release model fails by design, no matter how disciplined your team is.

The pre-disclosure pattern is the clearest evidence of this structural shift:

• 32.1% of newly tracked exploits in 2025 appeared on or before the CVE’s public disclosure date, an 8.5 percentage point increase over 2024.
• An estimated 28% of 2025 vulnerabilities were exploited on the exact same day as disclosure, or before any patch was publicly available.
• For high-severity findings assessed across customer environments, exploitation windows narrowed to mere hours after disclosure.

These figures are flagged as indicative rather than independently confirmed, but the direction is unambiguous.

The pre-disclosure attack window widened further in 2025, with VulnCheck finding that nearly 29% of CISA’s Known Exploited Vulnerabilities were attacked on or before CVE publication, up from 23.6% the previous year, confirming that the CVE disclosure system increasingly functions as a post-incident record rather than a forward warning.

Read those numbers against your own process and the implication is uncomfortable. For a meaningful share of newly disclosed critical flaws, your exposure window has already closed by the time your team opens their inbox on patch Tuesday morning. The question is no longer “when will we patch this?” It is “have we already been exposed?”

The economics of the attack AI-enabled frameworks can reportedly generate functional proof-of-concept exploit code in 10 to 15 minutes, at a cost of roughly one dollar per attempt. (Figure flagged as indicative.)

That cost figure is the one worth dwelling on. When weaponising a vulnerability costs about the price of a coffee and takes less time than a meeting, the economics of attack have fundamentally changed. AI has not simply made attackers faster. It has industrialised the process.

How AI turns a CVE into a working exploit

The mechanics are more mundane than you might expect. When a patch is released, attackers use automated patch-diffing, comparing the patched and unpatched versions of the code to infer exactly where the flaw sits. That inference then feeds into a large language model (a type of AI trained on vast amounts of text, including security research and CVE databases) which generates candidate exploit code.

University research demonstrates how far this already goes. GPT-4, operating as an autonomous agent, reportedly succeeded in exploiting 87% of tested one-day vulnerabilities when simply given the CVE description.

The autonomous exploit research from UIUC, published in April 2024, demonstrated that GPT-4 operating as an agent succeeded against 87% of tested one-day vulnerabilities when supplied only with the CVE description, providing controlled experimental evidence for the capability claims that threat assessments increasingly reference.

The takeaway is not that every attacker has this capability today. It is that the capability exists, it is cheap, and it scales. The slow, manual work of exploit development, once a genuine bottleneck in your favour, is being automated away.

What NCSC guidance actually requires when exploitation is active

If the threat has compressed, the regulatory standard has compressed with it. NCSC guidance is not a vague call for vigilance. It is a branching set of concrete obligations, and your specific situation determines which branch applies.

Start with the baseline. For routine updates to internet-facing services and software, NCSC guidance recommends testing in a staging or backup environment and completing deployment within five days. That is the normal-weather standard.

Active exploitation changes everything. The trigger is inclusion on the CISA Known Exploited Vulnerabilities (KEV) catalogue, a public list of flaws confirmed to be exploited in the wild. The moment a vulnerability lands on KEV, your generic change window closes and the NCSC decision matrix activates.

That matrix sets remediation timeframes based on four factors: KEV status, internet accessibility, whether the exploit can be automated, and whether it enables total control of the system.

CIR denotes a cyber incident response process running alongside the patch. The pressure these timeframes create is intensifying: the median time for a vulnerability to be added to CISA’s KEV catalogue reportedly fell from 8.5 days to 5 days over a recent two-year period, meaning the trigger arrives sooner than it used to.

There is one requirement here that organisations miss most often, and it carries the heaviest consequences.

Check before you patch If an internet-facing service is being actively exploited, NCSC guidance states you must investigate your exposure and check for signs of compromise before applying any update, even if exposure was brief. Patching over an already-compromised system can destroy forensic evidence and leave attacker footholds in place.

Treat this framework as the floor, not the ceiling. For a UK organisation, these thresholds represent the minimum competent-response standard. In any post-incident regulatory or insurance review, a failure to meet them in an actively exploited scenario will feature prominently. Knowing in advance what tips a flaw into the sub-24-hour tier lets you build a real escalation process now, rather than improvising when the advisory lands.

How AI changes what “good enough” vulnerability management actually looks like

Here is where many teams go wrong under pressure. They treat patching as a ticketing exercise: sort by CVSS severity score, work top to bottom, close the tickets. In an AI-speed environment, that approach can waste your fastest hours on the wrong targets.

AI-powered cyberattacks have moved well beyond theoretical concern: a three-person team using Claude Opus 5 moved from initial reconnaissance to a working exploit inside a major code repository in under 72 hours, a timeline that makes any patching process measured in days structurally inadequate as a primary defence.

The severity score alone is an insufficient signal. A critical-rated vulnerability sitting on an isolated internal server may matter far less than a medium-rated flaw on an internet-facing system wired into sensitive data. Context, not the score, should drive your urgency.

Four questions should shape every triage decision:

• Is the affected technology actually in use in your environment?
• Is the system reachable from the internet?
• Is active exploitation currently happening?
• What is the blast radius, the downstream damage, if an attacker gets in?

A single exposed, connected vulnerability frequently outranks several critical flaws buried on isolated infrastructure. This is the lens that makes the NCSC matrix usable rather than mechanical.

The risk also runs the other way. Patching badly can be worse than patching slowly. Applications carry complex dependencies, and a rushed update deployed without testing can trigger outages that exceed the security impact of the vulnerability itself. The evidence that this risk is real is not theoretical: 27% of MSP-related attacks in the first half of 2025 exploited known, unpatched flaws (figure flagged as indicative), which tells you that the balance between speed and safety is where real-world damage lives.

When not to patch immediately

Sometimes immediate patching is unsafe. NCSC guidance offers endorsed alternatives, and they run in a clear order of operational preference:

1. Isolate the affected system from the wider network.
2. Take the service offline temporarily while you assess.
3. Replace it entirely with a freshly built system from a known-good baseline.

Each buys you time without leaving the flaw live and exposed.

One rule holds regardless of the path you choose: verify the outcome. Offline devices and silent installation failures are common sources of false assurance, where a patch is nominally “deployed” but was never actually applied. Post-deployment verification is not optional. In a patching emergency, your job is not to move fast across everything at once. It is to triage ruthlessly and act with precision on the highest-risk exposure first.

What to ask your MSP before the next critical advisory lands

Most of the analysis so far assumes you control your own patching. Many UK organisations do not. They rely on a managed service provider, and that is where a quiet accountability gap tends to hide until the worst possible moment.

The structural problem is contractual. MSP agreements are commonly optimised for uptime and strict change-control compliance, not time-bound security obligations like “patch a KEV flaw within 24 hours.” That misalignment means emergency patching often needs escalation pathways that simply do not exist in your contract.

Multi-tenant architecture sharpens the risk. When an MSP runs a shared platform across many clients, conservative change windows exist to protect all of them at once. Your emergency can be quietly deprioritised by operational caution on behalf of the many. And the escalation chain compounds it: urgent patch requests frequently route through account managers and change advisory boards rather than straight to technical teams, turning a response that should take hours into one that takes days.

Put these five questions to your MSP now, before a vulnerability forces the conversation:

1. Asset coverage: Exactly which assets and software categories do you patch, and which remain our responsibility?
2. Threat identification: What is your process for determining when a newly disclosed vulnerability affects our specific environment?
3. Emergency escalation: What is the threshold for acting outside scheduled windows, and who approves it?
4. Compensating controls: What isolation or mitigation measures apply when a patch cannot be safely deployed?
5. Deployment verification: How do you confirm successful deployment across all systems, including devices that were offline?

The first question is the most revealing. If your MSP cannot immediately state what falls inside and outside their scope, you do not actually know your own attack surface.

The coverage blind spot MSP contracts frequently cover operating system patching automatically, but third-party applications, firmware, firewalls, and network hardware often sit outside the arrangement, without the client realising it. This is the gap most likely to surprise an organisation that believes it is fully covered.

If you cannot answer these five questions from your current contract, you are effectively operating without a defined emergency response posture, however solid your day-to-day arrangements look.

The standard to hold yourself and your MSP to in 2026

The through-line of everything above is a single shift. Patch management is no longer a scheduled maintenance function. It is an intelligence-driven, contractually specified emergency response capability, and it needs to be treated as one.

That arc from 745 days in 2020 to roughly 44 days in 2025 is not there to alarm you. It is there to explain why the changes described here are not optional refinements. They are necessary adaptations to an environment that has already moved.

You now have the benchmarks to measure against: the NCSC five-day routine standard and the sub-24-hour emergency threshold for actively exploited, internet-facing flaws. Hold both your own organisation and your MSP to them.

Responsibility sits with you, not the MSP alone. The provider executes, but you must define the obligations, verify the coverage, and escalate when the process falls short of the NCSC standard. In most UK organisations, the distance between current practice and that standard is not a technical gap. It is a contractual and process gap, closeable with the right questions and the right SLA language.

So make the MSP conversation a scheduled, documented review tied to the NCSC guidance update cycle, not a one-off.

For readers wanting to understand the industry-wide response to these pressures, our dedicated guide to the AI cyberattack warning and what it means for security budgets covers the CISA data showing 51% of scanned organisations run unsupported software, and the infrastructure gaps that rising budgets may not close.

This article is for informational purposes only and should not be considered financial advice. Investors should conduct their own research and consult with financial professionals before making investment decisions.

Several figures referenced here are flagged as indicative and have not been independently confirmed. They illustrate direction and scale rather than precise, verified measurements.