AI bug-hunting models pushed Microsoft's four-month patch total to 4.5 times its old baseline

The arithmetic is worth doing by hand. Add August's nearly 400 fixes to the three record months and June through September comes to roughly 1,820 ^[3][11]. At the old baseline of about 100 a month, those same four months would have produced 400 ^[1]. That is about 4.5 times the volume, or 1,420 extra fixes to read and route in one summer ^[11].

Two caveats sit on top of that number. The September figure comes from unnamed sources ahead of the release and covers Windows alone, per The Verge ^[4]. And none of the monthly totals tell you how many fixes apply to your estate, because the reporting names remote code execution and privilege escalation among the classes in the queue but does not break the count down by severity ^[9].

Deployment tooling scales, but the reading does not: triage, and the change-advisory sign-off in front of it, are people-time, sized when Microsoft's monthly release was a known quantity ^[8]. Applying a patch was never the hard part. Microsoft's own engineers spent the summer verifying hundreds of important fixes before shipping them ^[9]; the same verification happens again, from scratch, in every shop that receives them.

Most patch policies say every fix is tested against critical business applications before it goes out ^[8]. In a month of 650, that is not what happens: a short list of named applications gets checked, and the rest goes out in rings and gets watched. That is a defensible process. It becomes dangerous only when nobody has written it down, because then the untested share is a number the person holding the pager discovers after the fact.

That gap gets closed by writing the policy down and sorting the queue on two axes rather than by CVSS alone. Axis one: is the flaw reachable from outside without credentials. Axis two: can you name the specific application that plausibly breaks if this ships untested. No name, remotely reachable: first ring, today. A named application, local access only: schedule it, test it, let it wait a cycle. Named application plus remote reachability is the only quadrant that earns an emergency window, and on any month's list it is far shorter than the headline count. The quadrant nobody staffs is the first one, which is where volume actually lands.

The division is straightforward: divide the month's volume by the number of patches a team genuinely regression-tests in a cycle. Anything above 1 is the share you are shipping on faith. The reason to compute it now rather than in October is the interval Anthropic reported: a model that turns a fresh disclosure into working exploit code in hours has closed the distance between a vulnerability being published and being usable to something shorter than most change windows ^[7]. The gap was always the risk ^[8]. The volume just made it harder to keep the gap short by working weekends.

That ratio will not be flattering. It is cheaper to argue about it in a planning meeting, with the June-to-September numbers on the table, than in an incident review.