570 CVEs in One Tuesday: Triaging the Biggest Patch Drop in Microsoft History Without Burning Out Your Team
The July 2026 record Patch Tuesday shipped 622 CVEs and two actively exploited zero-days. Here's an exploitation-first triage workflow that lets UK SMEs fix what matters first instead of drowning in the list.
On the second Tuesday of July 2026, Microsoft published 622 vulnerabilities in a single release. Two of them — a SharePoint remote code execution flaw and an ADFS authentication bypass — were already being exploited in the wild before most sysadmins had finished their first coffee. The support inboxes lit up within the hour. One of our clients, a 40-person accountancy firm in Derby, forwarded us a vendor bulletin with the subject line 'URGENT: Patch all systems immediately.' All 622 of them, apparently, by end of day.
That instruction is not just impractical. At this scale it is actively harmful, because it treats a critical zero-day being used against real organisations and a low-severity information disclosure bug in a component you don't even run as the same priority. If everything is urgent, nothing is.
The old advice — 'patch everything, patch quickly' — was written for a world where a big Patch Tuesday meant 50 CVEs. It has quietly died at this volume. What replaces it isn't cynicism about patching. It's triage: a repeatable way to sort the genuinely dangerous from the noise, so your team spends its limited hours on the handful of fixes that stop a breach rather than grinding through hundreds that change nothing.
Why CVSS scores stopped telling the truth
The instinct is to sort by CVSS and start at the top. It feels rigorous. It isn't.
CVSS measures theoretical severity — how bad a flaw could be if perfectly exploited under ideal conditions. It says nothing about whether anyone is actually attacking it, whether a working exploit exists, or whether the affected software is even installed on your network. Research across recent years has consistently found that the overwhelming majority of high-CVSS vulnerabilities are never exploited, while a small slice of medium-scored ones cause real damage.
Of July's 622 CVEs, roughly 80 were rated Critical. If your team tried to fix those 80 first, in order, you might not reach the ADFS zero-day for days — and it scored lower than several Criticals nobody will ever weaponise. Meanwhile the two flaws being exploited that week were the ones that mattered, full stop.
So the sorting question isn't 'how severe?' It's 'is this being used against organisations like mine, right now, on software I actually run?' That's the exploitation-first mindset, and it changes the order of operations entirely.
The triage decision tree
Here is the workflow we run for clients on the morning after a large Patch Tuesday. It's deliberately simple, because a process nobody can remember under pressure is no process at all. Work through the questions in order and stop as soon as a CVE lands in a bucket.
Question 1: Is it on CISA's Known Exploited Vulnerabilities catalogue, or flagged as actively exploited by Microsoft?
If yes, this is a Tier 1 emergency. Attackers already have working exploits and are using them. The July SharePoint RCE and the ADFS bypass both fall here. These get patched today, out of band if necessary, ahead of everything else. There is no debate and no change window that outranks this. If you can't patch immediately, apply the mitigation Microsoft publishes alongside the advisory — for the SharePoint flaw that meant disabling a specific feature until the fix could be tested.
Question 2: Does a public exploit or proof-of-concept exist, and is the affected asset internet-facing?
An unpatched flaw with published exploit code on an internet-facing server is a matter of when, not if. Automated scanners find exposed systems within hours of a PoC dropping. This is Tier 2 — patch within 48 to 72 hours. The combination is what matters: a public exploit on an internal-only system is a lower priority than the same exploit on your externally reachable VPN gateway or web server.
Question 3: Do you actually run the affected product, in a configuration that's exposed?
This is where most of the 622 evaporate. A huge share of any Patch Tuesday covers products a given SME never touches — specific Azure services, developer tooling, server roles that aren't enabled. If the ADFS bug lands and you use cloud-native identity rather than on-premises ADFS, that zero-day is simply not your problem. Filtering against a current asset inventory removes the majority of the list before you spend a minute of effort on it. This is why the inventory work matters more than the patching work: you cannot triage what you cannot see.
Question 4: Everything else.
What remains — real products, no active exploitation, no public PoC, or internal-only exposure — goes into your normal monthly patch cycle. Tier 3. These still get fixed, but on a schedule, tested, batched, and rolled out without anyone working a weekend. This bucket is usually the largest by count and the smallest by genuine risk.
What this looked like in July
For the Derby accountancy firm, 622 CVEs collapsed fast. They don't run on-premises ADFS, so the zero-day everyone was panicking about didn't apply. They do run SharePoint on-premises for their document management, so the SharePoint RCE went straight to Tier 1 — patched by 11am with the interim mitigation applied first while the update was tested against a spare server. Two internet-facing systems with published PoCs went into Tier 2 and were done by Thursday. The remaining several hundred CVEs affecting products they either don't run or don't expose went into the July monthly cycle.
Actual same-day emergency work: one patch. Not 622, not 80. One. That's the difference between a triaged response and a burnt-out team.
Building the workflow into your month
The decision tree only works if the supporting pieces are already in place before Patch Tuesday, not scrambled together on the day.
- Keep an asset inventory that's actually current. You need to answer 'do we run this?' in seconds. If checking takes an afternoon of asking around, triage fails at the first exposed CVE.
- Subscribe to exploitation feeds, not just severity feeds. CISA's KEV catalogue is free and authoritative. It tells you what's being exploited, which is the signal that outranks CVSS every time.
- Agree tiers and timelines in advance. Tier 1 same day, Tier 2 within 72 hours, Tier 3 monthly. Write it down so nobody debates the rules during a crisis.
- Protect the monthly cycle. The point of triage is to shrink the emergency list so the routine list can be handled calmly, tested, and rolled back if a patch breaks something.
Record-breaking Patch Tuesdays will keep coming; 622 will look modest before long. The organisations that cope aren't the ones patching fastest. They're the ones who decided, before the flood arrived, exactly which drops they were going to catch first.
If your team is still trying to patch everything on the day, we can help you build a triage process that fits your actual estate — and stop treating every Tuesday like an all-nighter. That's the kind of quiet, unglamorous groundwork that keeps small businesses out of the breach headlines.
