Windows October 2026 Patch Triage: Prioritize Exploited CVE-2026-96951 Over CVSS and EPSS

Below is a version-scoped walkthrough of that workflow, checked against public data on October's exploited flaw. It points out where the scripts help and where they could give you false confidence.

Why the CVE count matters less than the exploited flaw​

The guide starts by admitting that nobody agrees on the October number. CSO Online's roundup reported 1,407 CVEs, beating the 2020 record of 1,261, and said the list was large enough that Microsoft published it hours late. The same article quoted Fortra's Tyler Reguly using 1,413. BleepingComputer's headline, as indexed by vulnerability aggregator Vulmon, says Microsoft October 2026 Patch Tuesday fixes 1,411 flaws, 3 zero-days. That makes at least three counts for one release.

The guide puts the gap down to different handling of re-released entries, third-party components and cloud-only advisories. That's believable, though it's an explanation, not something Microsoft has confirmed. The practical advice holds up anyway: count from your own filtered copy of the primary feed and write down how you counted, so your ticket totals can be reconciled later.

Reguly's point in CSO Online makes the case well. He said 26 Microsoft CVEs from 2026 have landed in CISA's KEV catalog so far, which is less than 1% of what Microsoft has patched this year. Zero Day Initiative's Dustin Childs told the same publication that teams who triage by raw CVE count rather than exploitability are "burning cycles on the wrong bugs."

Section summary: Pick one counting method and stick to it. Your first priority is exploitation evidence, not the size of the release.

The flaw at the top of the list: CVE-2026-96951​

The single exploited entry is a Windows Shell security feature bypass. In practice it defeats Mark of the Web, the tag Windows puts on downloaded files that triggers SmartScreen and Protected View warnings. Public records match the guide:

• What it is: OpenCVE's record describes improper neutralization of special elements used in a command ('command injection') in Windows Shell allows an unauthorized attacker to bypass a security feature over a network.
• How it's used: An attacker sends a crafted file by email or instant message; if the victim opens it, Mark of the Web (MotW) protection does not apply.
• Severity: Microsoft rates it Important. One write-up lists the CVSS 3.1 vector as AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. So it needs no authentication, but a user has to open the file.
• KEV timeline: CISA added CVE-2026-96951 to the KEV catalog on 13 October with a remediation deadline of 16 October 2026 for federal agencies.
• Workarounds: Updates are available for all listed Windows versions; Microsoft does not list a workaround.
• Windows 10: Threat Frontier reports that Windows 10 PCs outside the Extended Security Updates (ESU) program do not get this one.

The flaw is part of a pattern. CSO Online quoted Tenable's Satnam Narang saying this is the third exploited Windows Shell flaw of 2026, and that 26 Windows Shell CVEs have been patched this year, compared with three in 2025.

EPSS gets this one wrong​

Public data adds something the guide doesn't mention. OpenCVE lists the CVE's EPSS score as 0.01512, about 1.5%, and tags it EPSS: 1.5% Low.

The guide's scoring model only gives EPSS points at a probability of 0.10 or higher. By EPSS alone, the one confirmed-exploited flaw of the month would score nothing. If a pipeline sorted by EPSS, or by CVSS, where an 8.8 sits below every 9.8 critical, this flaw would end up in the middle of the list.

FIRST's own EPSS FAQ explains why. When a vulnerability is in KEV but has a low EPSS score, FIRST's answer is simply "Follow KEV." By design, observed exploitation goes into model training, not into the daily score.

The guide says EPSS lags because the model "learns from observed activity with a delay." That gets the reason slightly wrong. The FAQ says recent exploitation intentionally does not move the daily score, partly because EPSS would otherwise publish exploitation data it isn't licensed to share. The practical conclusion is the same: treat KEV status and the vendor's "Exploited" flag as overriding signals, and use EPSS as a tiebreaker.

Section summary: October's real-world threat had a medium CVSS score and a low EPSS score. Only exploitation evidence put it at the top.

Prerequisites​

The pipeline has two parts, both run from one admin workstation:

According to the guide, none of the three feeds needs an API key. FIRST separately confirms EPSS data is free with no registration. The guide says October's updates cover Windows 11 26H2, 26H1, 25H2, 24H2 and 23H2, plus Windows Server 2025, 2022, 2019 and 2016. It also says Windows 10 Enterprise LTSB 2016 stopped getting updates on October 13, so those machines should be treated as replacement projects, not patch tickets.

The 12 steps​

Steps 1–2: Set up and take inventory​

Create a working folder (the guide uses C:\patch-triage) with a Python virtual environment and folders for cached feeds, output, fixtures and tests. Then write a tags.csv that records the three things Microsoft can't know about each machine: its role, whether it's internet-facing or internal, and how critical it is.

The PowerShell collector reads four things from each machine over WinRM:

• Product name. Windows 11 builds of 22000 and above are labelled "Windows 11 Version XXHX"; on servers the edition suffix is removed.
• Full build string including UBR, built from CurrentBuildNumber and UBR under HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion.
• Pending-reboot status, from the Component Based Servicing RebootPending key and the Windows Update RebootRequired key.
• Tag values, merged into inventory.csv.

You can sanity-check builds against public data. Wikipedia's Windows Server 2022 entry lists the latest release as 21H2 (10.0.20348.5761) (October 13, 2026. A Server 2022 machine reporting a UBR below 5761 hasn't taken the October update. That includes the guide's own sample host at 20348.5700. For the 26100 branch, OpenCVE's configuration data for CVE-2026-96951 shows one x64 product entry as vulnerable below "versionEndExcluding": "10.0.26100.33650".

Watch out: the collector uses -ErrorVariable so one unreachable laptop doesn't stop the run, and it only prints a warning for that host. Nothing further down the pipeline treats a missing host as unpatched. If you skip the warnings, the report can look clean when it isn't. Reconcile unreachable hosts by hand every time.

Steps 3–4: Download and flatten Microsoft's monthly CVRF document​

Microsoft publishes each month as a CVRF document named by year and month, such as 2026-Oct, on the v3.0 API. The guide suggests a quick curl.exe test that pulls the JSON and prints its DocumentTitle before you write any code.

The Python engine then flattens each vulnerability into a record, using these parts of Microsoft's Threats array, as described in the guide:

• Type 0: impact (for example Remote Code Execution)
• Type 3: severity label
• Type 1: exploitability string containing Exploited:Yes, Publicly Disclosed:Yes and the "Latest Software Release" likelihood phrase

It also stores the KB number and FixedBuild for each product from the Remediations block. Comparing builds is the important design choice. A KB check breaks once a newer cumulative update supersedes the old one, but a host at or above the fixed build stays fixed.

The guide also limits the run by default to entries whose first revision falls on Patch Tuesday itself. The monthly document picks up entries published on other days, so without this filter your counts will balloon.

Step 5: Check KEV, including vendors other than Microsoft​

The engine loads the whole KEV catalog into a dictionary keyed by CVE ID. A second script, kev_watch.py, filters recent KEV additions against a plain-text list of vendors you actually run. The guide recommends running it every morning, because KEV additions don't follow Patch Tuesday.

The guide cites October KEV additions for Ivanti Connect Secure and BeyondTrust Remote Support, and a joint CISA/FBI advisory on SafePay ransomware. I couldn't independently confirm those details, so treat them as the guide's claims. The principle doesn't depend on them: a Microsoft-only pipeline leaves your VPNs and remote-support tools unwatched.

Be clear about what KEV legally requires. As CISA's own alerts explain, Binding Operational Directive 22-01 only binds federal civilian executive branch agencies, and CISA "strongly urges" everyone else to prioritise catalog entries. Threat Frontier reports that the required action for this CVE includes following CISA's BOD 26-04 and follow its Forensics Triage Requirements. In plain terms: when a flaw was exploited before you patched it, check your logs as well as applying the update.

Step 6: Match CVEs to hosts by build​

For each CVE and host, the engine checks whether the host's product string appears in Microsoft's product name, ignoring case. It then checks whether the host's build is below the fixed build on the same branch, meaning the first three build numbers match. That stops a 25H2 machine being judged against a 24H2 fix.

The case-insensitive match is there because, according to the guide, one Windows 11 26H1 product entry in the feed spells "version" in lowercase. A case-sensitive match would skip those laptops without telling you.

If no fixed build shares a branch with a host, the row is labelled manual instead of guessed. The guide lists these October packages for checking results:

Microsoft's Windows 11 release-health page confirms KB5127648 shipped on October 13. Check the other rows against Microsoft's own KB pages before using them as gospel.

Step 7: Score and assign tiers​

Points are additive and loosely follow the four factors the guide attributes to CISA: KEV status, exposure, automated-exploitation potential and technical impact.

• 60 points for KEV listing or Microsoft's Exploited flag
• 15 for "Exploitation More Likely/Detected"; 10 for public disclosure; 10 for EPSS ≥ 0.10
• 10 for RCE (5 for elevation of privilege or security feature bypass); 10 for Critical or 5 for Important; 5 for CVSS ≥ 9.0
• 15 for internet-facing hosts (5 for internal); 5 if any affected host is high-criticality

One hard rule: only confirmed exploitation can produce P0. Without it, a theoretical critical RCE on an internet-facing server could outrank a flaw attackers are using right now. Tiers then become deadlines: P0 in 3 days, P1 in 7, P2 in 14, P3 in 28. Twenty-eight days from October 13 lands on November 10, the next Patch Tuesday. For KEV entries, the engine replaces the generated date with CISA's due date.

These are the guide's own internal service levels, not a Microsoft or CISA standard. FIRST notes that 0.10 is a commonly quoted EPSS threshold with "no special authority." It also warns against multiplying EPSS by CVSS. The guide's additive scheme avoids that, but it is still a heuristic ranking, not a calibrated risk score.

Step 8: Run it​

Run it against the bundled fixture first. It uses fake CVEs dated 2099 and should give one P0, one P1 and one P3. Then run it against 2026-Oct and your real inventory. The CSV includes tier, score, KEV flag, EPSS, revision count, affected hosts, KBs, due date, a build/manual check column, and a "why" column listing which signals fired. That last column is handy when someone in the change meeting asks why their favourite bug isn't first.

Step 9: Roll out in rings​

The guide suggests these starting values:

P0 items skip the ring schedule. For lab machines, the guide shows DeferQualityUpdates and deadline values set under HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate. It recommends Intune or Group Policy for production. The guide also mentions AD FS hardening enforcement, an Exchange stability warning and hotpatch eligibility. I couldn't verify those, so check Microsoft's release-health notes before relying on them.

Steps 10–11: Verify and track revisions​

Collect inventory again, run the engine again with --refresh, and confirm the P0 and P1 rows have closed. On a patched fleet, CVE-2026-96951 should change to NOT-IN-FLEET. Anything left should be manual: .NET, image extensions and other components that version separately from the OS build. Then filter for hosts where pending_reboot is true. A staged update is still running the old binaries.

The pending-reboot flag tells you a restart is outstanding. It doesn't prove which update is waiting, so check the build after the restart. And don't trust Get-HotFix alone, as the guide warns.

Microsoft revises monthly entries after release. A month-wide run with --refresh that lists entries with more than one revision will catch them. Cached feeds hide these changes.

Step 12: Schedule it​

A weekly scheduled task runs every Tuesday under a service account, collects inventory, and starts the engine with --only-patch-day. The engine exits quietly unless that day is the second Tuesday. The KEV watcher runs separately every day. A small unittest suite covers the second-Tuesday calculation (October 13 and November 10, 2026), build comparison, case-insensitive matching and the tier rules.

What's good about it, and what it misses​

Strengths:

• It ranks by exploitation evidence first, which is the lesson October teaches.
• It verifies by build number, not KB presence, so patches don't count until the new binaries are actually running.
• It labels rows it can't check as manual rather than marking them green.
• It keeps the same rules every month, which ends arguments about whose count is right.

Limitations:

• It is not production-ready as published. The guide itself says to test it in a lab first. Unreachable hosts are only warnings, so a complete-looking CSV can be missing machines.
• Component blind spots. .NET, SharePoint, Exchange and Office need software-inventory checks. CSO Online notes that two of October's three zero-days were in SharePoint (CVE-2026-102866) and .NET Framework (CVE-2026-108398). An OS build comparison can't see either, even though neither was confirmed exploited.
• The weights are opinions. That's fine if they're documented, tuned against past months and matched to how fast your team can actually patch. As the guide puts it, a seven-day deadline you miss every month teaches people to ignore deadlines.
• There's already a commercial version of this. Tools such as Defender Vulnerability Management and similar scanners do the same correlation. This pipeline is best seen as a transparent, auditable cross-check on those tools, or a stopgap if you don't have one.

Bottom line​

If CVE-2026-96951 isn't closed on every machine yet, you're already past CISA's federal deadline. Patch internet-facing machines and anything that handles email, downloads or Office documents today. Then look through logs for suspicious files opened before the patch, because a Mark of the Web bypass works by suppressing the warning users would otherwise see.

The rest of the guide's process holds up beyond October: rank by exploitation, prove fixes by build, assume unknown machines are unpatched, and refresh your data before every review. The next run is November 10, 2026.