CVE-2026-81963: local privilege escalation in the Windows Update Stack through link following

The lead we had to withdraw

This research began with a question about the boundary of an older fix, not with a CVE number. CVE-2020-0728 had closed a privileged entry point in Windows servicing. We wanted to know whether that check protected the other paths through wcp.dll, the component that handles package files for TrustedInstaller. A scan found many file operations that would follow a reparse point. That gave us candidates, not a vulnerability: we still needed a standard user who could choose a path, reach one of those operations, and cause a protected write.

Our first route was through a CBS session exposed by COM. We recovered method signatures from the binaries and symbols, then tried Initialize, AddSource and Finalize. On 1 May our notes even called the result a “breakthrough”: the calls returned far enough into CBS to look promising. Then we checked the filesystem trace. The claimed TrustedInstaller accesses were not verified; the repeat capture found none at the path we controlled. We crossed out the conclusion. A successful COM call and a package-format error were not evidence of a privileged write.

There was a second trap in the test setup. CBS COM activation admitted an interactive standard-user logon, while an SSH logon carried a network token. An ACCESS_DENIED from SSH could not settle whether the interface was available to the user we actually cared about. We moved the low-privilege check to an interactive session and kept the negative SSH result as a warning about test context, not as a product defence.

The two extractions that mattered

We changed the search from “which public method reaches a file operation?” to “where does CBS handle the same package twice under different identities?” In the OnePackage path, CreatePackage extracts CAB content while impersonating the caller. Later, EvaluateApplicability calls ExternalEvaluateApplicability, which extracts again without restoring that impersonation. The session retains the working path between calls. We could control that path, and the file-opening code followed its redirection when it was used again. Unlike a timing race, the change happened between two calls we controlled.

The first proof was deliberately modest. On Windows 11 23H2 build 22631.6937, we began as a non-admin user, confirmed that account could not write to the protected destination, and let CBS process a test package. The redirected second extraction wrote there under TrustedInstaller. We repeated the write three times. The result of EvaluateApplicability could still be an error after the write; treating that return code alone as failure would have hidden the bug. We checked the file and its ownership instead.

A privileged write is not automatically a complete elevation. We built and tested a separate route from that write to code execution, then checked the resulting SYSTEM token. The complete chain succeeded three times on 23H2 and three times on Windows 11 25H2 build 26200.8246. These counts describe our tested builds, not every Windows configuration. We keep the executable and the precise execution destination out of this article; the important research lesson is where each proof boundary sat.

A stronger control before the report was closed

On 4 May 2026 we sent Microsoft the root cause, the low-privilege-to-SYSTEM proof and the build-specific evidence. That evening we added an interactive SYSTEM demonstration; MSRC opened case 115491 the following day. During the exchange we separated the two impacts more carefully. On 15 May, in a fresh Canary VM snapshot, we tried a direct write to a component-store location as SYSTEM and got Access is denied. After restoring the snapshot, a smaller harness exercised only the CBS write path: it placed a canary in that same location, without invoking the later SYSTEM execution route. We restored again and checked that the canary and payload were absent. This control showed why calling the flaw merely “a way to get SYSTEM” missed the TrustedInstaller write boundary. It does not by itself prove every proposed policy-tampering scenario.

Microsoft published CVE-2026-81963 and its fix on 8 September. On 9 September we replayed the original standard-user path on fixed Windows 11 25H2 build 26200.9445. It stopped with 0x80070005 before the privileged second extraction. We also investigated a related write still visible on that build, but it reached only an attacker-controlled location; we found no operation carrying it to a protected target. We did not call that a bypass. Our Server 2025 review was static, not a Server VM replay.

What the public advisory adds

Microsoft’s advisory classifies the issue as link following and improper access control (CWE-59, CWE-284), scores it 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) and reports exploitation detected. CISA added it to KEV on 8 September 2026. Microsoft credits our researcher alongside researchers from the Microsoft Threat Intelligence Center. Neither notice says that the attacks Microsoft observed used our reported sequence, or identifies an actor. Our account above comes from the research and MSRC case, not from an inference about those attacks.

Affected builds and action

Product	First fixed build	Update
Windows 11 23H2	22631.7582	KB5122880
Windows 11 24H2 / 25H2	26100.9445 / 26200.9445	KB5124008
Windows 11 26H1	28000.2954	KB5124012
Windows Server 2025	26100.33438	KB5122871

Install the applicable September 2026 update or a later cumulative update. Prioritise shared hosts where a local low-privilege process may already run. Compare the installed build with the appropriate row; Windows Server 2022 is absent from Microsoft’s affected-product list for this CVE, and our original Windows 11 chain was not reproduced on that server version.

A rule for every junction near a servicing directory would generate noise. We have not published the exploit path, so we cannot offer a reliable path signature. If investigating a suspected attempt, preserve servicing, process and filesystem telemetry and correlate it with an unusual local privilege transition.

Timeline

Date	What we established
1 May 2026	Withdrew the initial AddSource/Finalize “breakthrough” after checking the missing filesystem proof
2 May 2026	Reproduced the protected write from a standard user and connected it to SYSTEM execution on 23H2
4–5 May 2026	Reported the chain to MSRC, updated the demonstration and received case 115491
15 May 2026	Compared a denied direct SYSTEM write with a successful isolated TrustedInstaller write in a restored VM
8 September 2026	Microsoft published the fix and reported exploitation; CISA added the CVE to KEV
9 September 2026	Original route stopped on fixed build 26200.9445; related write did not reach a protected target