Two exploited Windows bugs, two routes to SYSTEM privileges

Microsoft’s September release includes two local privilege-escalation bugs with reported exploitation. Both can lead to SYSTEM privileges. That combination deserves attention even though Microsoft rates the affected entries Important rather than Critical.

Two Windows issues with reported exploitation

Microsoft’s September release data flags CVE-2026-81963, affecting the Windows Update Stack, and CVE-2026-85880, affecting Windows Advanced Local Procedure Call (ALPC), as exploited. Microsoft describes both as local privilege-escalation vulnerabilities and says successful exploitation can result in SYSTEM privileges. Both are rated Important in the affected-product entries we reviewed.

Both issues increase the authority available on a computer an attacker can already act on. Neither is described here as a standalone remote-entry flaw. The Important rating and the report of exploitation are separate facts to consider when setting priority.

Microsoft’s CVE-2026-81963 advisory

Microsoft’s CVE-2026-85880 advisory

Microsoft’s September 2026 release data used for this review

CVE-2026-81963: unsafe file-link resolution

For the Windows Update Stack issue, Microsoft identifies improper link resolution before file access, mapped to CWE-59 and improper access control. An authenticated local context can gain privileges it should not have. The advisory supplies that classification, but does not identify the patched function.

Microsoft’s Windows Update Stack CVE record

A filesystem path names an object; links can change which object is ultimately reached. A privileged service must apply its access decision to the object it actually uses, rather than trusting an earlier interpretation of the path. CWE-59 covers failures to handle that indirection correctly.

MITRE’s explanation of unsafe link resolution, CWE-59

A lower-privilege caller must not be able to steer a privileged component’s file operation beyond the caller’s permitted access. Microsoft does not publish the path, operation or timing sequence involved here. That leaves no basis for identifying a particular race or treating permissions on a guessed directory as a fix.

CVE-2026-85880: heap corruption in ALPC

Microsoft describes CVE-2026-85880 as a heap-based buffer overflow in Windows ALPC. ALPC is a local communication mechanism used in Windows; its name does not mean the vulnerability is an internet-facing remote procedure call. The disclosed outcome is local elevation to SYSTEM, with an authenticated local prerequisite.

Microsoft’s Windows ALPC CVE record

Heap buffers hold dynamically allocated data. Writing past an allocation can corrupt nearby program state, with consequences that depend on the affected code and its protections. Microsoft identifies that failure class for this CVE, but does not provide the allocation layout or a full account of the corrupting operation.

MITRE’s explanation of heap-based buffer overflow, CWE-122

What SYSTEM access means for an investigation

LocalSystem is a highly privileged Windows service identity with extensive local access. It is not synonymous with a human administrator account or automatic domain-wide control. Microsoft documents that a service running under this identity also presents the computer’s credentials to remote resources, whose permissions remain relevant to the resulting scope.

Microsoft’s LocalSystem account documentation

These bugs can turn a limited foothold into a more serious endpoint compromise. They do not explain how the attacker first got in. Keep initial access, privilege changes and subsequent activity as separate lines of inquiry. Installing the patch will not resolve an independently compromised account or explain what ran before the update.

Use the update for the installed Windows branch

Match the release, architecture and servicing arrangement to Microsoft’s affected-product table and cumulative update. Record the package, resulting OS build and restart status. The Windows Update Stack name in a CVE does not mean an unrelated servicing-stack package from another Windows release will fix the machine in front of you.

Build the rollout around affected machines

Microsoft’s release data maps fixes to particular products and builds. Use the affected-product and security-update entries for the exact Windows version, edition and architecture you operate. Do not assume a single KB number from another organization’s report is the right package for your entire fleet.

Start with confirmed affected devices, then consider their roles. An administrator’s workstation, a kiosk and a server with a critical dependency may need different maintenance plans. Assign an owner to coordinate testing and restarts on the difficult systems so their exceptions do not become indefinite.

• Confirm the installed product and build against Microsoft’s affected-product information.

• Assign the applicable security update through the business’s established update system and check relevant vendor installation notes.

• Record failed installations, offline devices and deferred restarts separately from completed machines. Give each exception an owner and a deadline.

Track restarts through to completion

Microsoft’s Windows Update guidance explains that a restart may be needed to finish installation and shows where users can review installed updates. On Windows 11, that history is available under Settings, Windows Update, Update history. Scheduling the restart should be part of the update task rather than a handoff nobody tracks.

Microsoft’s Windows Update guidance and update-history instructions

Keep the post-installation build or update result together with the restart outcome. An offered package has not necessarily been installed, and an installed package may still need a restart. If the management platform has not heard from a laptop, mark its status unknown.

Review the devices left over

A rollout can look almost complete while an administrator’s travel laptop remains deferred. Review exceptions by the work those devices do, not just their share of the fleet.

Close the maintenance work with verified applicable updates, completed restarts and assigned exceptions. If you also have signs of compromise, continue the incident investigation. The patch corrects the vulnerability; it does not explain unexplained privileged activity that happened earlier.

Source check: September 8, 2026. This is Short Circuit LLC’s analysis of Microsoft’s published disclosures, not a claim of original vulnerability discovery.