Microsoft Patch Tuesday for September 2026 fixes two Windows vulnerabilities that Microsoft says attackers have already exploited. The release is unusually large, but the practical priority is narrower: deploy the updates covering CVE-2026-81963 and CVE-2026-85880 first, then test and stage the rest according to exposure.
- Both exploited flaws allow a local attacker to elevate privileges to SYSTEM on Windows.
- Published totals differ because researchers count CVEs, product updates and earlier-in-month fixes differently.
- Security teams should use Microsoft’s product-specific guidance instead of treating the headline total as a deployment order.
- The operational bottleneck is now testing and rollout capacity, not simply finding vulnerabilities.
Everyone else is reporting a record patch count; we are explaining why the count varies and how defenders can convert the release into an evidence-based rollout queue. Microsoft’s Security Update Guide is the primary record, while current-event reports from BleepingComputer, Ars Technica, KrebsOnSecurity, CyberScoop and Dark Reading provide independent counts and operational context.
Microsoft Patch Tuesday: what changed
The September release addresses a broad set of Microsoft products, including Windows, Office, Exchange Server, SQL Server, Azure services and developer tools. Microsoft’s own release material should remain the source of truth for whether a particular product and build is affected, because third-party totals are summaries assembled with different inclusion rules.
The common point across reputable coverage is more important than the disputed headline number. Two vulnerabilities were being exploited before fixes were available: CVE-2026-81963 in the Windows Update Stack and CVE-2026-85880 in Windows Advanced Local Procedure Call, or ALPC. Both are elevation-of-privilege issues that can let an attacker who already has local access gain SYSTEM-level rights.
| Item | Verified finding | Why it matters |
|---|---|---|
| CVE-2026-81963 | Windows Update Stack privilege escalation; exploitation detected | Could turn an existing foothold into SYSTEM control |
| CVE-2026-85880 | Windows ALPC privilege escalation; exploitation detected | Raises the urgency for affected Windows endpoints |
| Headline total | Published estimates range from the mid-960s to 974 | Counting method changes the total, not device exposure |
| Release date | 8 September 2026 | Starts the enterprise testing and deployment cycle |
Why reports disagree on the vulnerability total
BleepingComputer counted 966 flaws released by Microsoft on Patch Tuesday itself. Tenable’s analysis counted 964 CVEs. Ars Technica reported roughly 972, while KrebsOnSecurity, CyberScoop and Dark Reading cited 974. Those figures are not necessarily evidence that one outlet made a simple arithmetic error.
Patch totals can include or exclude non-Microsoft CVEs, CVEs issued earlier in the month, republished entries, or one vulnerability affecting several products. Some researchers count only new Microsoft-assigned CVEs in the monthly batch; others use Microsoft’s wider release-note inventory. That is why a precise deployment plan should be built from affected products and assets, not from a single headline number.
September’s Microsoft security release is operationally urgent because two Windows privilege-escalation flaws were exploited, not because one counting method produces the largest total. Teams should patch the affected Windows systems first, then sequence the remaining updates by exposure, exploitability and application risk.
The two exploited Windows flaws
CVE-2026-81963: Windows Update Stack
Microsoft describes CVE-2026-81963 as an improper link-resolution issue before file access in the Windows Update Stack. An authorised local attacker could exploit the weakness to elevate privileges. BleepingComputer reported that successful exploitation can lead to SYSTEM privileges and that Microsoft had not disclosed details of observed attacks.
The phrase “authorised attacker” does not make the issue harmless. It indicates that exploitation begins after some degree of local access. In a real intrusion, elevation-of-privilege bugs are valuable because phishing, stolen credentials or another vulnerability may provide an initial foothold without full administrative control.
CVE-2026-85880: Windows ALPC
CVE-2026-85880 affects Windows ALPC, a mechanism used for communication between local processes. Microsoft also marked exploitation as detected. Independent reports consistently describe it as an elevation-of-privilege vulnerability capable of reaching SYSTEM privileges after local access.
These two flaws should be considered together in triage because they occupy the same attack-chain role. Neither is described as a remote, unauthenticated entry point, but either could help an attacker convert a limited account or process into control of the endpoint.
What enterprise teams should do first
Start by identifying Windows builds and server roles covered by the two exploited CVEs. Confirm applicability in Microsoft’s Security Update Guide and product support pages, then compare that inventory with internet exposure, administrative use and endpoint criticality. Devices used by privileged administrators and systems that bridge identity or management networks deserve earlier treatment.
Next, deploy to a small canary group that represents critical hardware and line-of-business software. A canary is not a reason to delay exposed systems indefinitely; it is a way to detect compatibility failures before a wider rollout. Define a time-box for observation and an emergency path for systems whose risk exceeds normal change windows.
Microsoft’s Exchange Server support page illustrates why product notes matter. The September Exchange update lists resolved vulnerabilities as well as known issues involving published calendars and delegated-mailbox availability in some hybrid environments. Teams running Exchange should read those release-specific notes instead of assuming a generic Windows test covers the server workload.
After rollout, verify that the correct update is installed and that the asset has returned to policy compliance. A dashboard that says a deployment job ran is not proof that every endpoint accepted the update, rebooted when required, and now reports the expected build.
Why the record size changes patch operations
Microsoft says artificial intelligence is helping discover more vulnerabilities. Independent coverage also points to the human constraint that follows: every additional fix can require inventory analysis, compatibility testing, change approval, deployment and verification. Discovery capacity can scale faster than enterprise maintenance capacity.
That imbalance makes prioritisation more important, not less. The wrong response is to ignore the long tail because the list looks impossible. The better response is to separate emergency exposure reduction from routine lifecycle work, automate evidence collection, and reserve manual review for high-impact systems and failed deployments.
Security leaders should also explain count uncertainty to executives. Reporting “974 flaws” as if all are equally exploitable on every device creates noise. A defensible executive update should state how many affected assets exist, which exploited vulnerabilities apply, what percentage has been patched, what exceptions remain and when verification will finish.
India and global enterprise relevance
For Indian enterprises with distributed branches, shared services and outsourced IT operations, the release is a test of asset visibility. Remote endpoints, legacy Windows deployments and business applications tied to month-end or regulatory workflows can make a uniform same-day rollout unrealistic. Risk owners need a documented exception path rather than silent delay.
Managed service providers should give customers evidence at the asset level and reconcile different counting conventions before presenting compliance statistics. The release also complements broader interest in automated security operations. Lapaas Voice recently examined how Performance Agents keep humans in the coaching loop and how Apica’s Venn assistant adds governed observability workflows; patch automation needs the same combination of machine speed and accountable human review.
A practical verification checklist
Before closing an emergency change, operations teams should capture five pieces of evidence: the affected asset list, the applicable Microsoft bulletin or CVE record, the deployed update identifier, the resulting operating-system build and any documented exception. That evidence connects vulnerability intelligence to configuration state and prevents a successful deployment job from being mistaken for complete remediation.
Exceptions need owners and deadlines. A server held back for application testing should record the business service, reason for delay, compensating control, decision maker and next review time. Network restriction, privilege reduction or temporary service isolation may reduce exposure while compatibility work continues, but each control should be verified rather than assumed.
Rollback planning also belongs in the patch decision. Teams should know whether uninstalling an update is supported, what data or configuration must be backed up, and how they will restore service if a critical workload fails. For internet-facing or privileged systems, the risk owner may decide that restoring from a tested image is safer than leaving an exploited weakness open.
What leaders should measure after deployment
The clearest measure is not the number of patches downloaded. It is the share of applicable, exposed assets that reached a verified fixed state within the agreed service level. Report exploited-CVE coverage separately from the wider monthly batch so emergency progress is visible.
Track failed installations, devices awaiting reboot, assets missing from the management platform and exceptions older than their deadline. Those categories reveal whether the underlying problem is package compatibility, endpoint connectivity, incomplete inventory or change governance. They also create a feedback loop for the next Microsoft Patch Tuesday rather than repeating the same scramble every month.
Finally, review how long it took to move from vendor release to asset-level applicability, canary deployment and verified completion. A large security release is not only a vulnerability event; it is a stress test of the organisation’s software inventory, ownership records and ability to make reversible changes quickly.
Frequently asked questions
How many vulnerabilities did Microsoft fix in September 2026?
Major sources report totals ranging from 964 to 974 because they use different counting rules. The two exploited Windows vulnerabilities and product-specific applicability are more useful for deployment decisions than the headline total.
Which September Microsoft vulnerabilities were exploited?
Microsoft marked CVE-2026-81963 in the Windows Update Stack and CVE-2026-85880 in Windows ALPC as exploited. Both are local elevation-of-privilege vulnerabilities.
Should every update be installed immediately?
Exploited and exposed vulnerabilities deserve emergency treatment. Other updates should move through an accelerated but controlled test-and-deploy process based on affected products, business impact and rollback readiness.
Where should administrators verify affected products?
Use Microsoft’s Security Update Guide and the relevant product support page. Independent summaries help with context, but Microsoft’s product records determine applicability and installation guidance.
Sources
- Microsoft Security Update Guide release notes
- BleepingComputer release analysis
- Ars Technica release analysis
- KrebsOnSecurity release analysis
- CyberScoop release analysis
- Dark Reading release analysis
Get the day’s top stories in your inbox
One concise email. No spam, unsubscribe anytime.
