The Link Was Checked Too Late: CVE-2026-81963

fsutil reparsepoint query returns a tag where an ordinary directory should be. A few seconds later, update servicing starts, and a protected object changes under a SYSTEM process. The first event looks like filesystem trivia. The second looks like routine maintenance. The security signal exists only when the two are joined.

This is a composite defensive scenario, not a reconstruction of a reported intrusion. It frames the central problem in CVE-2026-81963: Microsoft describes an improper link-resolution flaw in the Windows Update Stack that allows a locally authorized attacker to elevate to SYSTEM. The September 8 advisory assigns CVSS 7.8, requires low privileges, requires no user interaction, and marks exploitation as detected. CISA added the vulnerability to the Known Exploited Vulnerabilities catalog the same day, with a September 22 remediation due date for organizations governed by its directive.

The name passed validation. The object did not.

Windows reparse points let a filesystem object redirect name resolution to another location or another filesystem filter. Junctions and symbolic links are familiar examples, but the important abstraction is broader: the pathname presented by an untrusted process is not necessarily the object a privileged consumer eventually opens. Microsoft documents that the reparse tag and associated data are interpreted during filesystem processing, which can alter how the remaining path is resolved.

CWE-59 captures the failure mode. A program checks a link before operating on its target, or authorizes a pathname without binding that decision to the final object. If an attacker controls any traversed component, a privileged write, delete, move, or permission change can land outside the intended tree. Robust designs authorize the resolved object and keep that identity stable through the operation, commonly by using handles and link-resistant open semantics rather than repeating name lookup.

The phrase “link following” does not prove a race condition. It also does not identify the attacker-controlled path, the privileged file operation, the trigger, or whether exploitation depends on a junction, symbolic link, mount point, or another reparse mechanism. Microsoft has not published those product-specific details. Treating a generic symlink primitive as the CVE exploit would be fiction.

How an operator would reason about the chain

The attacker already needs local code execution in a low-privilege context. That makes this an escalation stage, not initial access. In a realistic chain, a malicious document, browser compromise, exposed remote tool, or poisoned developer dependency provides the foothold. The next question is not “Can I run code?” It is “Which privileged service will operate on a namespace element I can influence?”

1. Map writable namespace edges. The operator inventories directories, temporary objects, inherited ACLs, and service-created artifacts accessible from the current token.
2. Observe a privileged consumer. Update activity supplies a SYSTEM-level file operation. The exact CVE trigger is undisclosed, so defenders should not assume a public request sequence or path.
3. Introduce a resolution boundary. A reparse object causes a checked name and a consumed object to diverge. Whether this requires timing is unknown.
4. Convert the primitive into impact. The privileged action reaches an object the low-privilege process could not modify directly. Follow-on execution, persistence, or credential access depends on what operation and destination the real exploit exposes.
5. Reduce noise after SYSTEM. A careful operator avoids a conspicuous shell if the modified object can execute later through a trusted path. That shifts detection toward the handoff rather than the terminal process.

This distinction matters operationally. Endpoint teams often search for a final SYSTEM child process while the more durable evidence sits earlier: a reparse artifact created by an unexpected user process, update servicing in the same time window, then a protected-file mutation. The same trust-boundary pattern appeared in ShieldBreak, where a privileged security component consumed attacker-influenced path resolution. The products and bugs differ, but the defensive question is identical: who controlled the namespace when authority crossed it?

A safe mechanism lab, not a Windows exploit

The following loopback-free Python lab isolates one property: lexical containment accepts a path under public/, but opening that path follows a link into private/. The fixed function resolves the candidate first and requires the resolved object to remain under the trusted root. It uses fictional data and does not reproduce Windows Update Stack code, paths, triggering, race behavior, or exploitability.

from pathlib import Path

def vulnerable_read(root: Path, requested: str) -> bytes:
    candidate = root / requested
    candidate.relative_to(root)          # checks only the lexical name
    return candidate.read_bytes()        # follows the link

def fixed_read(root: Path, requested: str) -> bytes:
    candidate = (root / requested).resolve(strict=True)
    candidate.relative_to(root.resolve(strict=True))
    return candidate.read_bytes()

The executed fixture placed public/package.link over private/system.conf. The vulnerable read returned the fake secret; the resolved-object check rejected the escape:

VULNERABLE_DISCLOSURE=True
FIXED_BLOCKED=True

This lab deliberately demonstrates disclosure because it is easy to verify without changing a host. CVE-2026-81963 is an elevation-of-privilege vulnerability. The shared lesson is the authorization error around object identity, not equivalence of impact.

Detection has to survive missing exploit details

Patching is the primary control. Microsoft’s machine-readable September 2026 CVRF document lists fixed builds, including 26100.33438 for Windows 11 24H2 and Windows Server 2025, and 22631.7582 for Windows 11 23H2. Product branches differ, so compare the installed product and servicing branch with the applicable KB rather than treating one build number as universal. KB5122871, for example, is the Windows Server 2025 security update and requires a restart.

$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
[pscustomobject]@{
  ProductName    = $cv.ProductName
  DisplayVersion = $cv.DisplayVersion
  Build          = "$($cv.CurrentBuild).$($cv.UBR)"
}

For threat hunting, start with scoped hypotheses instead of a guessed indicator. Inventory reparse points only in directories your update and endpoint engineering teams identify as writable or servicing-relevant. A recursive scan of an entire volume is expensive and produces weak context.

$Root = 'C:\Path\Approved-By-Endpoint-Engineering'
Get-ChildItem -LiteralPath $Root -Force -Recurse -Attributes ReparsePoint |
  Select-Object FullName, LinkType, Target, CreationTimeUtc

Then correlate four behaviors within a tight window: reparse-object creation or change by a non-administrative process, update servicing, mutation of a protected file or directory, and an unexpected SYSTEM-context consequence. Baseline legitimate package managers, enterprise deployment agents, cloud-file placeholders, and developer tooling before alerting. Reparse points are normal Windows machinery; rarity without ownership and temporal context is not a detection.

Sysmon Event ID 11 records file creation, but it does not by itself explain the final reparse target or prove abuse. Targeted Audit File System policy can add object-access evidence when a SACL exists on the relevant object. Neither source is retroactive. If the organization has not enabled scoped collection before exploitation, a hunt may need USN journal, EDR raw telemetry, servicing logs, and file-integrity history. Absence of one event should not close the case.

The decision points that matter now

First, prioritize by exploit status and reachable preconditions, not CVSS alone. CISA’s KEV entry and Microsoft’s “Exploitation Detected” assessment put this flaw ahead of equally scored issues with no observed abuse. A useful exposure query asks which Windows endpoints are unpatched and already exposed to likely footholds, unmanaged software, risky browser activity, or developer workloads.

Second, treat privileged file consumers as explicit trust boundaries in architecture and detection engineering. The method used in attack-chain threat modeling applies below the application layer: model the user token, the writable namespace, the privileged service, the resolved object, and the authority gained at each transition.

Third, keep vulnerability inventory separate from exploitability evidence. As with a VEX decision pipeline, the patch record answers whether a component is affected; endpoint evidence answers whether a specific asset offered the prerequisite and whether suspicious behavior occurred. Combining those views produces an actionable queue. Collapsing them into a scanner severity produces noise.

The small detail in this case is a name that stopped identifying the object everyone thought it did. The operational response is equally precise: install the correct servicing update, verify the resulting build, preserve namespace and file-operation telemetry, and hunt for the privilege handoff rather than waiting for a familiar payload.