Microsoft patches two Windows flaws already used in attacks

Two exploited flaws, not proof that every PC was attacked

Microsoft’s September MSRC bulletin identifies CVE-2026-85880 in Windows Advanced Local Procedure Call and CVE-2026-81963 in the Windows Update Stack as elevation-of-privilege vulnerabilities exploited before fixes were released. Canada’s Cyber Centre independently flags both identifiers. Neither notice establishes how many people were attacked or whether a particular reader’s computer was compromised.

Elevation of privilege describes an attacker gaining capabilities beyond the permissions they already have. It is not a synonym for a remote, unauthenticated takeover. An exploited flaw deserves prompt attention, but the useful next question is which systems and versions in your own inventory are affected—not how frightening the total patch count sounds.

What changed after the original September report

Our September 9 article said Microsoft listed no known issues at that check. That is no longer a current description. The revised support documentation records operational problems and subsequent fixes. This is a dated update to the report, not a claim that every device experienced those failures.

The table is deliberately limited to these two Windows 11 branches. It is not an instruction to install these packages on Windows 10, 23H2, 26H1, a server or an Insider channel. A later applicable cumulative update may include the earlier fixes; use the current support page for your exact edition, version and architecture rather than chasing the oldest KB number in this story.

What remains open—and what has a documented fix

At our October 1 recheck, the KB5124010 support page lists a further desktop-loading issue alongside the previously documented domain-trust and USB Audio Class 1.0 problems. The new notice mainly concerns Azure Virtual Desktop hosts using FSLogix after the August preview and later updates; affected sessions may show a black screen after sign-in. Microsoft's change log dates the added notice to September 25.

Microsoft documents a Known Issue Rollback (KIR) mitigation for this desktop-loading issue, including a version-specific enterprise Group Policy and restart. Affected administrators should consult that notice for their configuration and deployment policy. The page says a permanent resolution remains in progress. This is a bounded notice; it does not diagnose a reader's PC or justify rolling back security updates across a fleet.

The same page's September 29 change log adds Windows 11 26H2 to its applicability. Our dated release timeline remains explicitly scoped to 24H2 and 25H2. Domain-trust and USB Audio Class 1.0 symptoms still have their own notices; the File History fix remains documented in updates from September 22 onward. Dated source record and limits.

For the domain issue, administrators should inspect the precise configuration and Microsoft’s current guidance. This article does not recommend disabling security features generally, changing the registry speculatively or removing security updates as a blanket response. A home user with working audio should not assume an unrelated problem has the same cause.

Microsoft records the earlier Remote Desktop Services and HCS/Plan9 sharing problems as resolved by the September 14 release or later updates. Standard Hyper-V configurations without that Plan9 path were not the stated scenario. A resolved entry is a reason to test the affected workflow on a corrected build—not proof that every similar symptom has that root cause.

The File History failure is documented as fixed in the September 22 preview. If your backup was affected, check that new versions are being written and that a sample file can be restored; a connected drive or a reassuring icon alone does not demonstrate a usable backup. This check is our operational recommendation, not a Lumacta test result.

A practical completion check

1. 1 · Identify

   Know which machine and branch you are updating

   Record the Windows edition, version and installed build using the system’s own information screens. On an employer- or school-managed computer, ask the responsible IT team about its deployment status rather than sideloading a package yourself.

2. 2 · Complete

   Close the installation loop

   Check Windows Update and update history for success, failure or a pending restart. Save work and complete the required restart. Microsoft describes September’s baseline as requiring a restart, including in the hotpatch schedule; downloaded does not mean protection is already in effect.

3. 3 · Verify

   Check the functions that make the machine useful

   After the update, confirm ordinary sign-in, a short audio playback/recording check, required remote access and a sample backup restore. For a fleet, keep an owner and an exception list for offline, failed or restart-pending machines. Do not infer completion merely from the update having been offered.

Our conclusion: urgency with evidence, not a false all-clear

The security case for addressing exploited vulnerabilities has not disappeared because a rollout has known issues. The defensible approach is to prioritize affected systems, test representative configurations, apply the appropriate supported fixes and track completion. An organization should document any temporary exception and the compensating controls chosen by its security team.

Patching closes known weaknesses; it does not investigate what happened before installation. If there are credible signs of compromise, preserve relevant evidence and involve the responsible security team. Neither this article nor a successful update status can establish that the device is clean. We have not run these updates on a test fleet, inspected a reader’s machine or independently measured the incidents described in the notices.