Four Outlets Counted the Same Patch Tuesday. They Got 966, 973 and 974.

Microsoft shipped its September 2026 security updates on 8 September, and the number attached to them became the story within hours. The trouble is that there is no agreement on what the number is. BleepingComputer counted 966 flaws. Cybersecuritynews.com published 973 in its table and then referred to a headline total of 974 one paragraph later. SecurityWeek reported 974 and called it a record. Higher figures still are circulating.

Whichever you take, it is the largest Patch Tuesday Microsoft has released. It is also, as a measure of how exposed any particular organisation is this month, close to useless — and treating it as a risk signal is the specific error most likely to get somebody breached before October.

Here is the fact that should be leading the coverage instead. Both of the vulnerabilities Microsoft confirms are under active exploitation are rated Important. Neither is rated Critical.

The two that are actually being used

CVE-2026-85880 is a heap buffer overflow in the Windows Advanced Local Procedure Call subsystem. An attacker able to execute code inside a low-privilege AppContainer can use it to escape the sandbox and elevate to SYSTEM, with no additional user interaction. CISA added it to the Known Exploited Vulnerabilities catalogue with a remediation deadline of 22 September 2026.

CVE-2026-81963 is an improper link resolution before file access issue — link following — in the Windows Update Stack, the components responsible for installing updates. It allows a local attacker to elevate to SYSTEM. Microsoft confirms real-world exploitation without describing how the attacks worked. It is the first flaw in that component to be flagged as a zero-day among the seven resolved there over the past five years.

Both are elevation of privilege. Both are rated Important. Both are marked exploited but not publicly disclosed, which is not a contradiction — private exploitation routinely precedes public disclosure.

An organisation whose emergency patch process is defined as “deploy Critical items out-of-band, Important items in the normal window” has, this month, scheduled precisely zero of the vulnerabilities it is being attacked with.

What the number is made of

Take the 973 figure and its published impact breakdown from cybersecuritynews.com: 438 elevation of privilege, 258 remote code execution, 173 information disclosure, 56 denial of service, 19 security feature bypass, 16 spoofing, 13 tampering. Those seven categories sum to exactly 973, which is at least internally consistent — and is modest evidence for 973 over the 974 the same article uses in prose.

Now do the division nobody appears to have done. Elevation of privilege is 45% of the release. Every one of those 438 entries presupposes an attacker who already has code execution on the machine. They are post-compromise escalation paths, not front doors. Remote code execution — the class that describes something reaching in from outside — is 258 entries, or 27%.

The component split reported from Microsoft's release notes is 723 Windows, 111 Office, 62 SQL, 22 developer tools, 16 SharePoint Server and 9 Exchange Server, with 25 republished non-Microsoft CVEs listed separately. Windows alone is roughly three-quarters of the total. Exchange Server — an internet-facing product with a long history of mass exploitation — accounts for nine entries, under 1%.

There is one more piece of arithmetic worth stating because it goes to the reliability of the whole exercise. Those six component figures sum to 943, thirty short of the same article's own 973 total. The impact table reconciles; the component table does not. That is not a scandal — products get counted differently, some CVEs span components, and republished third-party entries sit outside the tally — but it is a concrete illustration of why four competent outlets read the same release and published three different totals.

Severity and required action are separate axes

The clearest single demonstration that the severity column is not a work queue is in this month's Critical list. CVE-2026-83941, a Critical-rated Entra ID vulnerability, is marked as requiring no customer action — Microsoft fixed it on the service side. Meanwhile the two Important-rated items above require every affected organisation to deploy an update, on a deadline CISA has now made mandatory for federal civilian agencies.

The rest of the Critical list is genuinely serious and none of it is under attack: CVE-2026-83939 in Windows Secure Kernel Mode, CVE-2026-83498 and CVE-2026-83501 in VBS Enclaves, and Office remote code execution issues CVE-2026-81959, CVE-2026-81953 in Excel and CVE-2026-81952 in Word. These should be patched. They should not displace the two that are being exploited today.

Severity ratings describe the theoretical worst case of a vulnerability in isolation. They say nothing about whether anyone has built a working exploit, whether it is being used, or whether the affected component exists in your environment. Those are the three questions that determine this month's actual risk, and the severity column answers none of them.

The case for severity-based triage, made properly

The counter-argument deserves better than a strawman, because it is close to correct in practice. An organisation confronting nine hundred-plus items in a single month cannot assess them individually. Most do not have a vulnerability-management function; most have one or two people who also run the helpdesk. For those teams, Microsoft's severity ratings are the only prioritisation signal that arrives free, on schedule and in a machine-readable form. A policy of “Critical now, Important this month, everything else next quarter” is imperfect but it is executable, and an imperfect policy that gets executed beats a sophisticated one that does not.

That argument holds right up to the point where the exploited vulnerabilities sit outside the emergency tier, which is where it sits this month.

The resolution is not to abandon severity triage. It is to add a second input that is already published, already free, and specifically built for this failure mode: the exploitation flag in Microsoft's own Security Update Guide, and CISA's Known Exploited Vulnerabilities catalogue. KEV named CVE-2026-85880 with a 22 September date. That is an exploitation-based signal, not a theoretical-severity one, and it identifies the correct two items out of nine hundred-odd without any judgement required from the person running the patch window.

What to do with an unstable denominator

The honest position on the count is that it cannot be stated to the unit. Depending on whether you include republished third-party CVEs, Adobe entries bundled into the same review cycle, Mariner and Azure Linux advisories, and CVEs assigned by other parties but shipped in Microsoft's rollup, the same release supports totals from the mid-960s to the mid-990s. None of the outlets reporting those figures is being careless; they are counting different things and mostly saying so in their methodology.

Which is the argument in miniature. A figure that shifts by thirty depending on editorial choices about what belongs in the set is a publishing artefact. It is a reasonable thing to note in a headline and an unreasonable thing to plan around.

Three practical consequences follow for anyone who owns a patch window this month. Deploy the two exploited elevation-of-privilege fixes on the emergency path regardless of their Important rating, with 22 September as the outside date. Check whether your triage policy has a severity threshold in it, because if it does, it just failed a live test. And stop reporting the monthly CVE count upwards as though it were a risk metric — the number that moved this month is not the number that matters.