Blog
12 Minutes vs. 7 Days: The New Math of Patching
Security & legacy

12 Minutes vs. 7 Days: The New Math of Patching

Key takeaways
  • In a test reported by the State of AI Report 2026, a frontier model built a working exploit for a known Firefox bug in 12 minutes; Windows Autopatch needs about 7 days to reach 90% of a fleet.
  • High- and critical-severity disclosures from 21 major vendors in H1 2026 exceeded their total for all of 2025.
  • Agents produced a functional patch for 65.9% of 920 historical vulnerabilities, but fixed the intended bug in only 22.2%.
  • Poland's amended KSC requires an ISMS and S46 connection by 3 April 2027; the EU CRA's 24-hour early-warning duty applies since 11 September 2026.
Two numbers from this year's State of AI Report frame the problem. In a reported test, a frontier AI model needed 12 minutes to build the first working exploit for a known Firefox bug — and produced working proofs of concept for 14 of 18 known bugs. Microsoft's Windows Autopatch, by comparison, needs about 7 days to reach 90% of a device fleet.
The distance between those two numbers is where patching risk now sits.

What changed in 2026

The patch queue grew

High- and critical-severity vulnerability disclosures from 21 major vendors in the first half of 2026 exceeded their total for the whole of 2025; critical disclosures rose almost fourfold in six months. The report is careful to note that CVE counts do not reveal who found a bug, so the share attributable to AI is unknown. The queue is longer either way.

Bug-finding scaled

Anthropic reports more than 33,000 high- or critical-severity findings across its partners and open-source scanning. These are findings, not published CVEs, but many will become patches that organisations have to apply.

Real intrusions used ordinary weaknesses

The report describes an operator who used more than 1,000 prompts to an AI coding tool to exfiltrate 150 GB from ten Mexican government bodies, and a security firm's agent that reached the database of a consultancy's internal AI platform in two hours by chaining 22 unauthenticated endpoints and a SQL injection. Neither relied on exotic zero-days. Unprotected endpoints, weak credentials and known holes were found faster.

Why legacy systems are hit hardest

An N-day is a vulnerability that is already public and already has a fix. For years, defenders relied on the time it took attackers to turn a published patch into a working exploit — often weeks. That buffer has largely disappeared.
A typical ten-year-old business system makes patching slow for structural reasons:
  • the framework is end-of-life, so no official patch exists;
  • nobody is certain which libraries and versions are inside;
  • there are no automated tests, so every update is risky and gets postponed.
In such a system, patching takes months while exploitation can take minutes.

AI does not simply patch it for you

The same report evaluated agents on 920 historical vulnerabilities in 139 real C and C++ projects. Working from source code alone, agents produced a functional patch 65.9% of the time — but only 22.2% of patches fixed the specific historical bug they targeted. Others fixed a different valid issue or merely stopped the crash.
A patch that compiles is not necessarily a patch that fixes. Engineers who understand the system still need to review it.

The regulatory clock in Poland and the EU

Under Poland's amended National Cybersecurity System Act (KSC), covered entities must operate an information security management system and be connected to the S46 system by 3 April 2027. Under the EU Cyber Resilience Act, manufacturers have had to send an early warning within 24 hours of becoming aware of an actively exploited vulnerability since 11 September 2026.
If a working exploit can exist minutes after a patch is published, a quarterly patch cycle is an accepted risk rather than a policy.

A 90-day plan to shorten patch time

  1. Know what runs. Keep an inventory of systems, frameworks, versions and end-of-life dates; for software you ship, maintain a software bill of materials (SBOM).
  2. Prioritise by exposure, not only by score. Internet-facing and known-exploited vulnerabilities first. A medium-severity bug on a public login page outranks a critical one on an isolated test machine.
  3. Make patching routine. Automated tests, a CI pipeline and staged rollouts turn a quarterly event into a weekly task.
  4. Isolate what cannot be patched. Segment the network, place a web application firewall in front of the system and set a replacement date.
  5. Track one metric monthly: time from patch release to patch in production.
Attackers became faster in 2026, but most of the weaknesses they used were old ones. Old weaknesses can be closed — the constraint is how quickly an organisation can ship a change safely.

Sources

  • Air Street Capital, State of AI Report 2026, slides 207–211.
  • Rödl & Partner and McCann FitzGerald, summaries of the amended KSC and the EU Cyber Resilience Act timelines.
  • European Commission, Cyber Resilience Act — official overview and application dates.