How to Prioritize a Record-Size Patch Tuesday Without Patching Everything First
When a release carries 970 CVEs, sorting by CVSS drowns you. Triage by exploitation status, network reach, user interaction and asset criticality to find the few that matter.
Microsoft's September 2026 Patch TuesdayPatchPatch🛡️A software update that fixes security vulnerabilities, bugs, or adds improvements to an existing program. Tuesday🛡️The second Tuesday of each month, when Microsoft releases its scheduled batch of security updates. The predictable cadence lets defenders plan deployment, but AI-assisted vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. discovery has pushed recent releases past 900 CVEs, straining triage. carried somewhere between 964 and 974 CVEs, the largest release in the company's history and roughly two and a half times the previous month. A team that responds to that by opening the list, sorting by CVSS, and working top to bottom will still be patching when the next Patch Tuesday arrives. The volume is not a temporary spike; analysts attribute it to AI-assisted vulnerability discovery inside vendors, and it is the new baseline. The only sustainable answer is a triage process that decides what to patch first from attributes other than raw severity score. This guide lays out a repeatable one.
Why CVSS Alone Fails at This Scale
CVSS measures the theoretical severity of a vulnerability in isolation. It is useful, but it answers the wrong question when you are staring at 970 of them. Two of the most important bugs in the September release, the exploited Windows Update Stack and ALPC zero-days, scored only 7.8 and were rated Important, not Critical. Meanwhile dozens of Critical-rated bugs affected components you may not even run. Sorting by score would have pushed the two flaws attackers were actually using down below bugs nobody had touched.
A score also cannot tell you whether a vulnerability is exploited, whether the vulnerable service is reachable from where attackers are, or whether exploitation needs a user to do something. Those attributes decide real-world risk, and they are exactly what a good triage process puts ahead of the number.
The Four Questions That Order Your Queue
For each significant vulnerability, or better, each group of related ones, answer four questions in order. The order matters, because each one filters the list before the next.
**Is it being exploited?** Confirmed in-the-wild exploitation, signalled by a spot in the CISA Known Exploited Vulnerabilities catalog or a vendor's "exploitation detected" flag, overrides everything else. The September zero-days went into KEV the same day they were patched, with a federal deadline of 22 September. An exploited 7.8 outranks a theoretical 9.8 every time, because one is a present-tense attack and the other is a possibility. Our coverage of the two exploited Windows zero-days is an example of the signal you are looking for.
**Can an attacker reach it?** A vulnerability in an internet-facing service is a different emergency from the identical bug on an isolated internal host. Within that, distinguish the perimeter from trusted internal infrastructure. The wormableWormable🛡️A vulnerability that can be exploited to spread automatically from system to system without user interaction, similar to how biological worms spread. bugs in the September release lived in DNS, DHCPDHCP🌐Protocol that automatically assigns IP addresses to devices on a network. and domain services that cannot be firewalled off from the clients they serve, which is why why wormable bugs in core Windows services change the patching calculus argues for patching that infrastructure ahead of higher-scored bugs elsewhere.
**Does it need user interaction?** A bug that fires with no click and no login is more dangerous than one that needs a victim to open a file, because it can be automated and it can spread. This is the attribute that separates a wormable remote bug from a phishingPhishing🛡️A social engineering attack using fake emails or websites to steal login credentials or personal info.-dependent one, and it should pull the no-interaction bugs toward the front.
**Does it affect something you actually run, and how business-critical is it?** A Critical flaw in a product you do not deploy is not your problem this cycle. Among the products you do run, a bug on the domain controllers or the payment system outranks the same bug on a lab machine. This is where an accurate asset inventory stops being a compliance checkbox and starts saving you time.
Turning the Answers Into Waves
Those four questions naturally sort a release into deployment waves.
The first wave is the exploited zero-days, patched out of cycle, everywhere they apply, ahead of the normal testing rhythm. In September that was the two EoP bugs; because one lived in the Update Stack itself, verifying the patch genuinely applied, by checking post-patch build numbers rather than trusting a deployment tool's status, belonged in this wave too.
The second wave is the wormable and internet-facing critical bugs, ordered by exposure: perimeter services and trusted internal infrastructure like DNS, DHCP, Netlogon and Active Directory first. These get emergency handling because their blast radius is the whole network.
The third wave is everything else that affects systems you run, patched on the normal monthly cadence with normal testing. This is where the bulk of a 970-CVE release lives, and treating it as routine is correct, provided the first two waves have been carved out and handled.
A fourth, standing item is the process itself. If it took you a day to work out which two of the September bugs were exploited, that is the thing to fix before next month, because the volume will not drop.
Buying Time and Staying Sane
You will never patch everything the day it ships, and you do not need to. Two habits make the gap survivable. First, use network controls as a compensating measure while patching is in progress: segmentation and access rules on exposed and infrastructure services are, in Microsoft's own words, a meaningful layer of defense during the window before a patch is deployed. Second, accept that a large CVE count is not the same as a large amount of danger. As several analysts put it after the September release, AI-assisted discovery is producing larger haystacks, not necessarily more needles. The teams that stay calm are the ones whose process reliably finds the few needles, exploited, reachable, interaction-free bugs on systems that matterMatter🏠A new universal smart home standard backed by Apple, Google, and Amazon for cross-platform compatibility., and lets the haystack wait for the normal cycle. The related patterns behind September's specific bugs are covered in how link-following bugs turn privileged file operations into SYSTEM access, if you want the mechanics behind the triage.