Microsoft's July Patch Tuesday broke its own record for the second month in a row. Depending on which outlet you read, it fixed either 622 vulnerabilities or 570. The gap between those two numbers is the first useful lesson of the month, and the record itself is close to the least useful thing in the bulletin.
Then, the day after, Microsoft blocked one of its own updates because it was making Dell laptops overheat and shut down. So this month gives us the whole of modern patching in a single week: a headline number designed to alarm, a small handful of fixes that actually matter, and a reminder that the patch itself is now a reliability risk. Let me take them in that order.
The number is theatre
Six hundred and twenty-two is Microsoft's own count from its Security Update Guide; the Zero Day Initiative counted 621. BleepingComputer's 570 is the same event counted differently — strip out some of the re-listings and the double-counted Office tracks (Microsoft lists the same 82 Office flaws twice, under separate product tracks, which is how other outlets get to numbers like 164 for Office alone) and you land lower. Neither number is wrong. They are measuring slightly different things, and the fact that a single Patch Tuesday can be honestly reported as 570 or 622 tells you how much weight the headline figure can bear. Not much.
Microsoft's own explanation for the swelling totals is, in part, artificial intelligence. It points to MDASH, its multi-model agentic scanning system, which it says found 16 of the bugs in May's release. That is a genuinely interesting development — if a vendor's own AI is now surfacing bugs at scale, the discovery treadmill is speeding up — but keep it in proportion. Sixteen out of six hundred is not the whole story, Microsoft has not said how many of July's came from that pipeline, and it has been setting records for months. The honest read is that the number is rising for several reasons at once, of which AI is one, and none of them change what you actually have to do on Wednesday morning.
Because here is the thing about 622. You are not going to be attacked by a number. You are going to be attacked, if you are attacked, through one specific flaw. The job is never to "apply 622 patches this week." It is to find the two or three that are on fire and deal with those first. So let us find them.
The three that actually matter
Of the whole pile, three are zero-days — and only two of those are being exploited right now.
CVE-2026-56164, in SharePoint Server, is the one to lose sleep over. It is being actively exploited, and it lets an unauthenticated attacker escalate privileges over the network. Unauthenticated and network-reachable is the worst combination there is: no credentials required, no user to trick, just a reachable server. If you run on-premises SharePoint — and a great many organisations still do, often forgotten, often internet-facing — this is a patch-tonight item. SharePoint has been a favourite target all year, and Microsoft's interim mitigation, if you genuinely cannot patch immediately, is to enable AMSI and set the Request Body Scan to Full. Do the patch anyway.
CVE-2026-56155, in Active Directory Federation Services, is the second exploited one. It lets an already-authenticated attacker elevate privileges locally. That sounds tamer than the SharePoint bug, and in isolation it is — but AD FS is identity infrastructure. It is the thing that federates logins across your estate, and an attacker who has a foothold and can elevate inside your federation service is an attacker on the cusp of owning authentication itself. Microsoft's own incident response team found this one being used, which tells you it is not theoretical. If you run AD FS, it goes on the same short list as SharePoint.
CVE-2026-50661, a BitLocker bypass, is the third — publicly disclosed, but not being exploited, and it needs physical access to the device. That last clause changes the urgency entirely. It is not a remote emergency. But it is not nothing either, and for my readers in particular it is worth a moment: if your people travel with laptops, or leave them in hotel rooms and cars, "an attacker with physical access can bypass the disk encryption" is precisely the threat model you bought BitLocker to defeat. Lower priority than the two exploited flaws, higher priority than the other 619.
That is the triage in one paragraph. Six hundred-odd fixes, and your genuine emergency list this week is two, with a third for anyone whose threat model includes lost or stolen devices. The headline number did not help you build that list. Reading the exploitation status did.
The next tier, before it becomes next month's headline
After the emergencies come the criticals — 59 of them this month, 48 of which are remote code execution. None are known to be exploited yet, but "yet" is the operative word, and the ones on exposed surfaces are where next month's incident write-ups come from.
Prioritise by exposure. The internet-facing and server-side criticals come first: remote code execution in the Windows DHCP service, in SQL Server, and a spoofing flaw in Exchange are the kind of thing that turns a single unpatched box into a foothold. Then the click-to-open surfaces: the crop of RCE bugs in Word, Excel and PowerPoint matter because they only need a user to open — or in some cases merely preview — a malicious document, and your users open documents all day. There is also a scattering of the genuinely eye-catching — remote code execution fixed in Microsoft Defender itself, in Copilot, and even in Minecraft — which is a reminder that "security product" and "attack surface" are not opposites.
You do not need to panic about these the way you do about the SharePoint bug. You need to get them into the normal cadence and make sure the internet-facing ones are near the front of it.
And then Microsoft broke its own patch
Here is the part that ought to temper anyone who thinks the answer to all this is simply "patch everything, immediately, everywhere."
The day after Patch Tuesday, Microsoft applied a safeguard hold to this month's Windows 11 update, KB5101650, on a range of Dell devices — blocking its own security update from installing. The reason: affected Dell laptops were suffering unexpected shutdowns, overheating, poor performance and battery drain. The root cause was not the security content at all, but a collision between Intel's Innovation Platform Framework driver and a new Windows USB-C connection-manager interface introduced in a June preview build. Two vendors' code met in an unexpected place, and the result was laptops turning themselves off.
Sit with the shape of that. In the same week Microsoft shipped six hundred security fixes, it also had to stop some customers installing them, because the cumulative update carrying those fixes was bricking their hardware in all but name. This is not a freak event. Cumulative updates bundle security and non-security changes together, they interact with a near-infinite matrix of drivers and firmware, and a meaningful minority of months something breaks. The patch is not free, and it is not risk-free.
What this actually means for you
The two facts of this month — a record number of fixes, and a fix that had to be withdrawn — pull in opposite directions only if you think patching is a single lever you pull harder. It is not. It is a process, and the teams that come out of a month like this intact are not the ones who patched fastest. They are the ones who triaged best and rolled out most carefully. Concretely:
Triage on exploitation and exposure, not on volume. The number of CVEs is noise. The signal is a much shorter list: what is being exploited, what is internet-facing, and what only needs a user to open a file. Patch the exploited flaws this week, the exposed criticals next, and let the long tail ride the normal cycle. If you are drowning in the 622, you are reading the wrong column of the spreadsheet.
Roll out in rings, never in one shot. The Dell mess is the whole argument for this. A pilot ring of representative machines, given a few days before the update reaches everyone, would have caught overheating Dells before they reached the whole fleet — exactly as Microsoft's own safeguard hold eventually did, only sooner and under your control. This is also why the 14-day patching window that standards like Cyber Essentials ask for is fourteen days, not fourteen minutes: the gap is there so you can test, not so you can dawdle.
Know what you own, or none of the above works. You cannot prioritise the SharePoint and AD FS fixes if you do not know whether you run SharePoint or AD FS, and you cannot ring-fence the Dell fleet if you do not know which machines are Dells. An accurate asset inventory is the unglamorous foundation the entire month rests on.
Read the release notes, not just the CVE count, and keep a rollback plan. Microsoft publishes known issues and safeguard holds alongside the fixes; they are the difference between installing KB5101650 on your Dells and not. And when something does go wrong — because periodically it will — the question is how quickly you can get back to a known-good state.
The record isn't the story
I have written before that patching is the unglamorous lifesaver, and nothing about a six-hundred-CVE month changes that. What it does change is the honest framing of the work. Defence is now a throughput problem: hundreds of fixes a month, arriving faster as automated discovery ramps up on both sides of the wire, some fraction of which will break something when they land. Heroic, patch-it-all-tonight energy is not the answer to that, and neither is the paralysis the headline number is designed to induce.
The answer is the dull discipline it has always been, just at higher volume: know your estate, patch the handful that are actually dangerous first, roll the rest out in rings so a bad update stops at ten machines instead of ten thousand, and keep a way back. The record will be broken again next month, almost certainly. Treat the number as weather. Do the triage.