Microsoft's October Patch Tuesday fixed 1,413 vulnerabilities, a record. (BleepingComputer counts 1,411, because trackers include slightly different things.) More than 70 were rated Critical, more than 300 allowed remote code execution, and 1,102 were in Windows. One, CVE-2026-96951 in Windows Shell, was being exploited before the fix was released.
If your patching process starts from "fix the Criticals first", October gave you more than 70 jobs, and a severity-sorted list wouldn't necessarily put the exploited flaw near the top. CVE-2026-96951 has a CVSS score of 8.8, below the 9.8s that usually lead such lists. It lets a crafted file evade Mark of the Web protections when a user opens it from email or chat, and CISA added it to its Known Exploited Vulnerabilities catalogue straight away.
Our view: at this volume, severity alone can't rank the work. What should rank it is whether a flaw is being exploited, whether the affected system is exposed, and what an attacker gets if it works.
The numbers are not going back down
Dustin Childs of Trend Micro's Zero Day Initiative put it plainly: "Hundreds of CVEs in a single release used to be the exception; now it's the baseline." He also said that "discovery is scaling faster than exploitation," and that AI is speeding up bug-hunting for defenders and attackers alike.
Vendors are changing their processes to match. In June, Cisco moved to a fixed twice-monthly release schedule, citing AI-accelerated vulnerability discovery and the shrinking gap between disclosure and exploitation. This month, Microsoft introduced risk cohorts, which group CVEs that need a similar assessment. Microsoft is careful to say that risk cohorts are "a starting point, not a final decision".
That's an honest description of where everyone is. The vendors can help sort the list. They can't tell you which of your systems matter most.
Why severity scores alone fail at this volume
- CVSS measures how bad a flaw could be, not how likely it is to be used. A Critical bug in a component you don't expose can matter less than a lower-scored one that's being exploited through email today.
- "Critical" no longer narrows anything. Seventy Critical fixes in one month is not a shortlist.
- The scores don't know your estate. The same CVE is urgent on an internet-facing server and much less urgent on an isolated test machine.
- Exploited bugs often aren't the highest-scoring. Attackers choose what works reliably against real users. User-interaction bugs, security feature bypasses and privilege escalations are their everyday tools, and they rarely score 9.8.
A better order of work
Here's the order we'd suggest for any month, not just this one.
- Exploited now. Anything Microsoft marks as exploited, or that appears in CISA's KEV catalogue, goes first, whatever its score. In October that's CVE-2026-96951. CISA gave US federal agencies until 16 October to fix it.
- Exposed and easy to reach. Next, flaws in systems reachable from the internet or by any user: mail servers, VPNs, remote access, collaboration platforms and anything that processes files from outside.
- Close to identity. Flaws in domain controllers, identity services and management tools. An attacker who gets these gets everything else.
- Publicly disclosed. Details are already out, so exploitation is more likely soon. October had two, including a .NET Framework flaw (CVE-2026-108398) that can bypass Windows Defender Application Control.
- Everything else, on schedule. The rest still gets patched, through your normal cycle and ring-based deployment.
None of this means patching less. It means deciding what goes first deliberately, rather than letting the order of a vendor's spreadsheet decide it.
Patching is half of it. Detection covers the rest
Even a good process leaves a gap between disclosure and deployment, and exploited zero-days arrive before any patch exists. That gap is where detection matters. For a flaw like CVE-2026-96951, the useful questions while you're patching are: which users opened files from email or chat that went on to launch scripts or executables? Which devices aren't yet on the update? Is anything on those devices behaving as if the exploit worked?
Prioritising by exploitability only works if someone is also watching for exploitation. A patch list tells you what you've fixed. It doesn't tell you whether anyone got in before you fixed it.
What to take away
- Expect four-figure Patch Tuesdays to be normal from now on, and plan staffing and tooling for that.
- Rank by exploitation, exposure and identity impact first. Use CVSS to break ties, not to set the order.
- Keep an accurate asset inventory, because "exposed" is a fact about your estate, not about the CVE.
- Pair your patch cycle with detection for whatever's still unpatched.
If you'd like help building a patch process that keeps up with this volume, or detection that covers the gap while it runs, talk to our team.