1,411 CVEs in One Patch Tuesday: How to Triage When Microsoft Breaks Its Own Record

On the second Tuesday of October 2026, a sysadmin in Beeston opened his patch management console, filtered for the month's new advisories, and stopped counting at a number he assumed was a bug. It wasn't. Microsoft had published fixes for 1,411 CVEs in a single Patch Tuesday — nearly double September's tally and, by most reckonings, more than the company shipped across the whole of 2025.

That figure includes a large batch of vulnerabilities inherited from a third-party component bundled into several Microsoft products, which is partly why the headline number looks absurd. But the practical effect on a small IT team is the same whether the count is inflated or not. The old plan — read the advisories, test everything, roll it all out within a fortnight — doesn't survive contact with a list that long. Something has to give, and if you don't decide what gives, the list decides for you.

This post is about making that decision on purpose.

Why 'patch everything' quietly stopped working

For years the advice to SMEs was reassuringly simple: keep your estate current, apply updates promptly, don't fall behind. It worked because the monthly volume was manageable. A team of two could reasonably read through 60 to 100 advisories, flag the nasty ones, schedule a maintenance window, and be done.

Scale that approach to 1,411 and the arithmetic falls apart. If you spend just two minutes assessing each CVE — reading the summary, checking affected products, noting the severity — that's roughly 47 hours of work before you've patched a single machine. For a three-person team juggling a help desk, a migration project, and the usual Tuesday fire, 47 hours of triage is a fantasy.

The instinct is to push everything out at once and hope the test environment catches the breakage. We've seen what happens next. One of our clients, a manufacturing business in Derby, did exactly that during a smaller spike last year. An update to a reporting component took down their production scheduling tool for a morning. The patch was legitimate and necessary — but it hadn't been tested against their specific setup because there was no time, and the rollback ate most of a day. Blanket urgency and blanket deployment aren't the same as good security. They just feel like it.

Not all 1,411 are your problem

Here's the first mercy: a huge share of any Patch Tuesday list doesn't apply to your estate at all. Vulnerabilities in Azure services you don't run, in developer tooling you've never installed, in server roles you turned off years ago — none of it is yours to patch.

So the very first filter isn't severity. It's relevance. Before you look at a single CVSS score, cut the list down to the products you actually run. A decent patch management or vulnerability scanning tool does this automatically by matching advisories against your inventory. If you don't have that, even a rough asset list — operating systems, Office versions, server roles, browsers — will strike out the majority of entries in minutes.

In a typical small UK business, a 1,411-CVE month might realistically touch 150 to 300 vulnerabilities. Still a lot. But it's a list a human can reason about rather than drown in.

Triage by exploitation, not by volume

Once you've got the relevant list, the question changes from 'how do I cover all of this?' to 'what will actually be used against me, and how soon?' That reframing is the whole game.

The single most useful tool here is CISA's Known Exploited Vulnerabilities catalogue — the KEV list. It's a public, regularly updated record of vulnerabilities that are being exploited in the wild right now, not in theory. If a CVE from this month's batch appears on the KEV list, it goes to the top of your queue regardless of its CVSS score. Attackers have working exploits. The window between 'patch released' and 'patch exploited' can be days or hours.

Build your priority order like this:

Tier 1 — KEV-listed and in your estate. These are non-negotiable. Patch them this week, out of band if necessary. Don't wait for the monthly maintenance window. For a UK SME, this tier is usually small — a handful of CVEs — which is exactly why it's achievable.

Tier 2 — Critical severity (CVSS 9.0+), network-exploitable, no authentication required. These are the ones most likely to join the KEV list next. Look specifically for vulnerabilities an attacker can hit remotely without already having a foothold — anything exposed to the internet, anything on your edge, anything on a server that accepts inbound connections. Schedule these within your normal cycle but near the front.

Tier 3 — High severity, but requiring local access, user interaction, or existing privileges. Genuinely important, less immediately dangerous. These fit comfortably into your standard patch window.

Tier 4 — Everything else that applies. Medium and low severity, awkward preconditions, limited blast radius. Patch in the normal run of things. Don't lose sleep.

The point of the tiers is that your scarce attention and your riskier out-of-band deployments get spent only on Tier 1 and the sharp end of Tier 2. The long tail still gets patched — just on a schedule that doesn't require heroics.

Read the CVSS vector, not just the number

A CVSS score on its own is a blunt instrument. A '9.8 critical' sounds terrifying until you notice it only applies to a role you don't run. Meanwhile a '7.5 high' on your internet-facing mail server might deserve action tonight.

The detail lives in the CVSS vector string — the part most people skip. Three fields tell you most of what you need:

• Attack Vector: Network, Adjacent, Local, or Physical. Network is the one that should raise your pulse.
• Attack Complexity: Low means it's easy to exploit. High means the attacker needs luck or specific conditions.
• Privileges Required: None is the worst case — no foothold needed.

A vulnerability that's network-exploitable, low-complexity, and needs no privileges is a far more pressing concern than a higher-scored one that requires an attacker to already be sitting on the box as an administrator.

Making it repeatable

The reason this model works for small teams is that it's the same every month. You're not reinventing your response to each new record. You run the same four steps: filter to your estate, check the KEV list, sort the remainder by exploitability, then deploy in tiers.

Write it down. A one-page runbook that any member of the team can follow turns a frightening headline into a Tuesday-afternoon task. It also means that when the next record falls — and it will — nobody panics, because the process doesn't care whether the number is 300 or 3,000.

A few things make the runbook stick:

• Automate the inventory match. Human relevance-filtering doesn't scale; tooling does.
• Subscribe to KEV updates so new exploited vulnerabilities reach you without you going to look.
• Keep a tested rollback path for Tier 1 out-of-band patches, so speed doesn't mean recklessness.
• Reduce your attack surface so fewer CVEs land in Tier 1 and 2 in the first place. Every internet-facing service you can close is a whole category of future patches you no longer have to rush.

The honest bottom line

You are not going to test and deploy 1,411 patches in two weeks, and you shouldn't try. Full coverage was always a comforting fiction; the record-breaking month just made the fiction impossible to maintain. What you can do — what actually protects the business — is make sure the vulnerabilities being exploited against organisations like yours are closed first, and fast.

Triage isn't a sign that you've given up on thoroughness. It's how thoroughness survives when the volume stops being survivable. Get the model right once, and the next terrifying headline becomes just another Tuesday.

If you'd like help turning this into a runbook for your estate — or you'd rather hand the whole monthly scramble to a team that does it every day — that's exactly the kind of thing we do. Get in touch.