Windows Zero-Day CVE-2026-81963: What to Do Now

Microsoft patched a Windows zero-day on September 8, 2026 that attackers are already using to gain SYSTEM-level access, and if your machines have not installed this month’s cumulative update and rebooted, that path is still open. That is CVE-2026-81963, a flaw in the Windows Update Stack, and Microsoft confirms it is under active exploitation. If you run Windows 11 or Windows Server 2025, today’s job is to confirm the September 2026 update installed, confirm each machine actually restarted, and verify that across your fleet instead of trusting that it happened. This note is the plain-English version of those steps, written for the person who just saw the advisory.

The source here is Microsoft’s own MSRC advisory, which lists the exploitation status as detected in active exploitation. It shipped as part of the September 2026 Patch Tuesday, alongside a second actively exploited privilege-escalation bug, CVE-2026-85880, in the Windows messaging layer. As of this writing the trade press has not published its Patch Tuesday roundups yet, so this is early. The facts below come straight from Microsoft. Actively exploited bugs like this also tend to land in CISA’s Known Exploited Vulnerabilities catalog, which is worth watching if you track KEV for compliance.

What’s actually broken

CVE-2026-81963 is a link-following flaw, scored 7.8. In plain English, the Windows Update Stack, the part of Windows that installs updates, can be tricked into following a file link it should not. An attacker who already has ordinary, low-privilege access to the machine sets up that link so the update process, which runs with full system rights, acts on a file the attacker controls. The result is that the attacker’s code ends up running as SYSTEM, the highest level of access on a Windows machine.

This is CWE-59, improper link resolution before file access, and the technical name is a privilege-escalation bug. Two things are worth being honest about. First, it is not remotely exploitable on its own. Someone has to already be running code on the machine, which usually means an earlier step: a phishing click, a malicious download, or another exploit. Second, that caveat is smaller than it sounds. Privilege escalation is the step that turns a single compromised standard user into full control of the machine, and from there a foothold into the rest of the network. Attackers chain it precisely because the first step is easy and this second step used to be the hard part.

There is a quiet irony worth naming: the flaw is in the update mechanism itself, the same machinery you use to fix it. That does not change the fix. It does mean the fix only counts once it is installed and the machine has restarted, which is the part teams miss.

The patch is only half the fix. We keep finding machines that installed the update weeks ago and never rebooted, so the hole is still wide open. On a fleet, we patch monthly and every machine actually rebooted are not the same sentence, and this bug lives in the update mechanism itself.

Kip LeGate, Chief Security Officer, azpentest

Who this affects

Anyone running Windows 11 version 23H2, 24H2, 25H2, or 26H1, on x64 or ARM64, or Windows Server 2025 including Server Core installations. Those are current, supported versions, so most Windows 11 desktops and laptops bought or updated in the last couple of years are in scope, along with any 2025-generation server.

Running Windows is not the finding here. Windows is supposed to be there. The finding, if there is one, is a machine that has not installed the September 2026 cumulative update, or has installed it and never rebooted. If you are not sure which version a machine is on, type winver in the Start menu and read the line at the top. Whoever manages your endpoints can answer for the whole fleet in a few minutes with the checks below.

What to do today

The update is the fix. The work is confirming it landed everywhere, because “we patch monthly” and “every machine is patched and rebooted” are not the same sentence. Whoever already manages your machines can run these. We are an independent second opinion, not a replacement for that person.

1. Confirm the September 2026 cumulative update installed. On a sample machine, open Settings, then Windows Update, then Update history, and look for a cumulative update dated September 8, 2026 or later with the status Installed. At the command line, Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 lists the most recent updates and their install dates.

2. Verify the build revision, not just the date. The most reliable check is the build number. Run winver and read the build, for example 26100.xxxx. The digits after the dot are the update build revision, and they climb with every cumulative update. Compare that number against the post-update build Microsoft lists for your specific Windows version in the September 2026 release notes. If your number is lower, the update is not actually on, whatever the history screen says.

3. Confirm the machine rebooted, and rebooted after the update. This is the step that gets skipped. The fix is only live after a restart, and an installed-but-not-restarted machine is still exploitable. Check the last boot time with Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime; if it predates the update install, the machine has not restarted since patching. A pending reboot also leaves a marker at the registry key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired. Restart the machines that need it.

4. Verify the whole fleet, do not trust the rollout. If you manage machines through Intune, WSUS, or an RMM tool, pull the actual report rather than assuming the policy worked. In Intune, check the quality-update compliance and the reboot-pending count. In WSUS, run the installation-status report for this month’s cumulative. In an RMM, filter to the September cumulative and to any device showing reboot pending. The common failure is a dashboard that reads “installed, pending reboot” while someone treats it as done.

If a machine has been running behind for months, that is worth a longer look than one patch. A fleet that is consistently a few cycles behind on updates is the real exposure, and this CVE is just today’s example of why.

The other zero-day from the same day

CVE-2026-81963 did not ship alone. The same September 2026 release fixed CVE-2026-85880, a separate flaw in the Windows messaging system that is also confirmed under active exploitation, and that one reaches Windows 10 and older Windows Server versions. Two actively exploited privilege-escalation bugs in one release is the reason to install the whole cumulative update and reboot, rather than cherry-picking or waiting for a quieter week. If you run a mix of new and older Windows machines, read that note too, because the affected versions barely overlap.

How you’d know if you were exposed

The honest answer to “are we exposed” is not about this one CVE. It is about whether your machines get patched and rebooted on a predictable schedule, and whether anyone checks. An internal penetration test is the independent version of that check. From a foothold inside the network, the kind an attacker gets from a phishing click, a tester looks for exactly this: machines running behind on updates, privilege-escalation paths from a standard user to SYSTEM, and the flat-network conditions that let one compromised machine become many.

A privilege-escalation bug like this one is a textbook internal-test finding, because it is the bridge between “someone clicked something” and “someone owns the domain.” Least-privilege accounts and MFA make that first step harder. Patching and rebooting close the second step. A test tells you, without waiting for an attacker, which machines still have that bridge standing. It is also how you answer an insurer or a board that asks whether your patch process actually works. Internal testing at azpentest starts at $6,500, retest included; the published tiers are on pricing.

Frequently asked questions

Is CVE-2026-81963 being actively exploited right now?

Yes. Microsoft’s own advisory lists it as detected in active exploitation as of the September 8, 2026 release. It is not a theoretical bug waiting for a proof of concept. Attackers are using it now to turn low-privilege access into full SYSTEM control on machines that have not installed this month’s update and rebooted.

What Windows versions does CVE-2026-81963 affect?

Windows 11 versions 23H2, 24H2, 25H2, and 26H1 on both x64 and ARM64, plus Windows Server 2025 including Server Core. Older Windows 10 machines are not listed for this specific bug, though a separate exploited flaw in the same release, CVE-2026-85880, does hit Windows 10 and older servers.

Is CVE-2026-81963 a remote attack, or does it need local access first?

It needs local access first. An attacker already running code on the machine, usually after a phishing click or another exploit, uses this flaw to climb from limited access to SYSTEM. It is a second step, not a way in on its own. That still matters, because that second step is exactly how one compromised login becomes control of the whole machine.

Do I need to do anything besides install the update?

Yes: reboot, and confirm the reboot happened. The fix is only live after the machine restarts. A fleet that installed the update but is waiting for users to click restart later is still exposed. Check that the last boot time is after the update installed, or use your management tool’s reboot-pending report.

Where you stand

Not sure whether your machines are actually patched and rebooted, or just reported that way? Tell us a little about your environment and what is prompting the question, and we will come back with a fair, fixed quote for an internal test that answers it. Request a quote.