Microsoft's biggest Patch Tuesday ever: what I'd actually fix first

I do this for a living - I get paid to break into companies and then explain, calmly, how I did it. So when Microsoft's July 2026 Patch Tuesday landed and my feed lit up with "570 flaws," "622 flaws," "record," "AI apocalypse," my first reaction was not panic. It was the same question I ask on every engagement: of all this, what actually gets someone owned - and what would I fix before lunch? This is that answer, written the way I'd brief a client.

So what actually happened?

Microsoft shipped the largest single Patch Tuesday in its history. The headline number depends on who's counting, and both are right: trackers that count only on-box products say 570 (BleepingComputer, Krebs, Qualys; Tenable says 569); those counting Microsoft's full Security Update Guide, including cloud and Edge entries, say 622 (The Hacker News, SecurityWeek, ZDI). Both figures exclude another ~427-468 republished Chromium/Edge CVEs. The gap between 570 and 622 is essentially the cloud/online-service and Edge fixes that need no action from you - so check the basis before you compare two headlines.

For scale: the previous record was 206 CVEs - set the month before, in June 2026. July is larger than the three prior months combined (The Register, The Record). This is not a blip; Microsoft has told customers to expect this to be the new normal. More on why in a second.

Why so many, all of a sudden? Microsoft's own AI.

This is the part the user in me finds genuinely interesting. Microsoft ties the surge to MDASH, an internal multi-model AI system it built to hunt bugs in its own code, first revealed in May 2026. Per The Register, MDASH found 16 of May's Patch Tuesday bugs by itself, and Microsoft warned customers to expect permanently larger releases. EVP Pavan Davuluri put it plainly (via Krebs): "advances in AI [are] making it possible to find more issues, faster, across more code."

The deeper debate this kicked off is real: when a vendor ships 570 fixes a month, is tracking individual CVEs even practical anymore? Help Net's take was blunt - people are "falling back to just patching as soon as possible." I land where the SANS handler did, and it's the sanest thing anyone said all week: you still own the same number of products. Patching a product doesn't take longer because the patch fixes more bugs. So stop sorting a 570-line spreadsheet by severity. Patch by product on a fast cadence, and spend your scarce human attention on the small subset that's exploited or exposed. Which brings us to that subset.

Here's the whole battlefield on one screen

Before we zoom in, this is how I mapped the month for myself - not by product name, but by attack surface, because that's how an attacker picks a door. Five clusters, and your assets sit under one or more of them:

The two bugs already being used against people

Three zero-days shipped; two are under active attack, and both were caught by incident responders inside real breaches - not theory. Here's why their modest scores are a trap:

CVE-2026-56155 (AD FS, 7.8) is an elevation-of-privilege in Active Directory Federation Services. The mechanism is a permissions gap on the DKM container - the thing that holds AD FS's token-signing key material. Reach that, and you can forge federation tokens and impersonate anyone. That's not a "7.8 local bug," that's your single sign-on trust root. Nasty detail: the patch ships in audit-only mode - you have to opt in to the actual fix with the RemediateDkmAcl registry key, or it won't tighten anything until October. Microsoft's own DART team found it in an active intrusion.

CVE-2026-56164 (SharePoint, 5.3) is the one that proves my whole point. Microsoft scored it 5.3, Moderate. NVD scored the same bug 9.8. It's a missing authentication check - an unauthenticated attacker escalates privilege over the network, no account needed. Mandiant found it in live incidents. CISA gave it the shortest deadline of the month. If you'd sorted by Microsoft's 5.3, it'd be on page four of your backlog while attackers walked in.

SharePoint is on fire again

If you run on-prem SharePoint, this month was a fire drill. Six CVEs, one target: an exploited missing-auth zero-day (56164), an exploited deserialization RCE (45659), an exploited spoofing bug (32201), a slick JWT authentication bypass (CVE-2026-55040, 9.1) that Rapid7's Stephen Fewer demoed at Pwn2Own - forge a token, become any user, including admins - and two unauthenticated 9.8 deserialization RCEs (58644, 50522). CISA issued a rare emergency hardening alert and gave agencies until July 17 to fix 56164.

The number that should bother you: Shadowserver counted roughly 10,000 internet-facing SharePoint servers, with 800-plus still unpatched against the exploited bugs days after fixes were out. This is the same on-prem SharePoint that got hammered by the 2025 "ToolShell" campaign - I can't attribute this year's activity to those actors (nobody publicly has), but the pattern is unmistakable: internet-facing on-prem SharePoint is a permanently farmed target. Get it behind auth and a WAF, or move it.

The stuff that keeps me up: pre-auth RCE on the perimeter

These are the bugs I'd probe for on an external engagement - unauthenticated, network-reachable, several at 9.8. No credentials, no user interaction. Prioritise the ones vendors flag Exploitation More Likely, then whatever you actually expose.

And the highest-scored bug of the whole release: CVE-2026-57092, a 9.9 use-after-free in Hyper-V's VMSwitch - a guest VM escaping to the host kernel. If you run multi-tenant virtualization, a hostile tenant in one VM can own the host and every VM on it. There's no workaround; patch the host, untrusted-tenant boxes first. We've got a full breakdown of this one in our research if you want the internals.

The new frontier: your AI assistant is now attack surface

This is the month AI-native products showed up in Patch Tuesday at 9.9 - SANS called it "the AI Acopolypse." Azure OpenAI (CVE-2026-45499) and Entra Provisioning (CVE-2026-57100) are both 9.9 server-side-request-forgery bugs used for privilege escalation. Microsoft Copilot (CVE-2026-48561, 9.6) is a web-to-AI command injection: a malicious website makes Edge for Android fire crafted prompts at Copilot, which acted without checking where the request came from.

Zoom out and the takeaway is strategic: treat AI assistants and their tool-connectors as privileged software. Scope their permissions, validate the provenance of what they ingest, and log what they do - the same way you'd treat any identity with that much reach.

And quietly, Secure Boot was broken for a decade

Not strictly part of Patch Tuesday, but it broke the same week and it's too good to skip. ESET found 11 old Microsoft-signed Linux UEFI shims - some dating to 2013 - that were never revoked, leaving Secure Boot bypassable on basically any machine trusting Microsoft's UEFI CA for about 13 of its 14 years. No exploit needed: an attacker just brings a copy of an old, still-trusted shim. The fix isn't a code patch - it's a revocation (a DBX denylist update). Which is the whole point: signed isn't safe, and patched isn't safe, until the denylist actually lands on the box.

How I'd triage 570 CVEs without losing my mind

Here's the exact order I'd work, and the decision flow behind it. It's boring on purpose - boring is what survives a 570-CVE month.

1. Exploited first. The two KEV zero-days (SharePoint 56164, AD FS 56155) go before anything, deadlines be your guide - even though they score 5.3 and 7.8.
2. Perimeter pre-auth RCE next. The 9.8 network set - network driver and DHCP are rated More Likely; then RDP, FTP, MSMQ. Patch or disable/firewall the role.
3. High-impact server and virtualization. VMSwitch (9.9) on Hyper-V hosts, SQL Server RCE, Exchange OWA.
4. The long tail on a fast product cadence. Apply cumulative product updates and stop per-CVE tracking the remainder.
5. Then verify. Re-scan the perimeter and confirm the exploited paths are closed - because 'patch released' is not 'patch applied and working'.

For network detection while you patch, Cisco Talos shipped Snort coverage - note they published SID ranges, not a per-CVE map, so load the ranges and cross-reference the rule descriptions:

The part everyone skips: did the fix actually close the hole?

Here's the trap I see on almost every engagement, and this month is a perfect example of it. The failure wasn't missing patches - fixes existed on day one. The failure was the gap between "we deployed it" and "the hole is verifiably closed." Shadowserver watched hundreds of SharePoint servers stay exploitable for days after the patch. A 'deploy successful' in your patch console and an attacker's scanner see two different realities.

A monthly patch cycle is a snapshot. Your exposure is continuous - new hosts appear, someone re-enables RDP, a WAF rule lapses. The discipline that closes the gap is simple to say and easy to skip: enumerate what you actually expose, confirm the exploited paths are gone after you patch, and re-check on a cadence - not once a month when Microsoft tells you to.

Scores and exploitation status as of 17 July 2026