CVE-2026-20965 Patch for Windows Admin Center Azure SSO Token Binding Flaw

A newly disclosed and patched flaw in Windows Admin Center’s Azure Active Directory Single Sign‑On integration undermined a fundamental trust boundary in cloud management: a local administrator on a single WAC‑managed VM could combine a stolen access token with a forged Proof‑of‑Possession (PoP) token to impersonate privileged users and execute commands across every Windows Admin Center instance in the same Azure tenant. The vulnerability, tracked as CVE‑2026‑20965, stems from improper token validation in WAC’s Azure extension and was fixed in the Windows Admin Center Azure Extension release 0.70.00 in mid‑January 2026; defenders must treat the issue as high priority for patching, hardening, and forensic review.

Background​

Windows Admin Center (WAC) is a browser‑based management tool used widely as a management plane for Windows servers, Azure VMs, and Azure Arc‑connected machines. In Azure environments, WAC’s convenience feature lets administrators connect to VMs from the Azure Portal using Azure AD SSO flows—delegated tokens and a PoP mechanism bind browser sessions to requests so administrators need not reauthenticate for each VM operation. This pairing of tokens is intended to prevent replay and cross‑session impersonation, but a mis‑implementation in WAC’s Azure SSO broke the binding assumptions. Researchers at Cymulate discovered and reported the issue to Microsoft in August 2025 and published a technical write‑up when Microsoft released the fix in January 2026. Public vulnerability tracking (NVD/third‑party advisories) lists the issue as CVE‑2026‑20965 with a high severity rating. The vendor remediation is the Azure Extension update to 0.70.00; administrators should confirm their installed extension version matches the fixed build.

---

What went wrong: the technical root cause​

Tokens in the WAC Azure SSO flow​

Two tokens play central roles in the vulnerable flow:

• WAC.CheckAccess — a service access token used by WAC to assert that a calling principal has the privileges to access and manage a specific WAC instance.
• PoP (Proof‑of‑Possession) token — a browser‑generated token cryptographically bound to a public/private key pair intended to prove the caller actually holds the private key and therefore the browser/session legitimately initiated the request.

For secure operation, WAC must verify both that (a) the access token grants the required privileges and (b) the PoP token proves the request originated from the bearer of the access token. In practice, WAC validated each token independently but failed to confirm they represented the same identity principal (for example, by matching user principal names or subject claims). This missing identity binding is the heart of the problem: a valid WAC.CheckAccess token from one identity could be presented alongside a forged PoP token crafted by an attacker, and the server would treat the pair as a valid SSO handshake.

Additional validation and exposure gaps​

The exploitability of this logic flaw depended on several operational and implementation weaknesses:

• Acceptance of non‑gateway URLs and direct IPs: PoP tokens that included non‑gateway DNS values or direct IP addresses were accepted. That allowed an attacker to target the VM’s WAC API endpoint directly rather than routing traffic through the Azure Portal gateway.
• JIT NSG behavior: Just‑In‑Time (JIT) opening of network security group rules commonly opens WAC’s API port (6516) broadly to source IPs during portal sessions. The temporary NSG openings made it practical for an attacker with local admin rights to talk directly to the WAC API during a privileged admin’s portal session.
• Weak replay/nonce enforcement: Reused nonces and acceptance of arbitrary HTTP methods in some code paths reduced the effectiveness of PoP anti‑replay protections.

Together, these factors let an attacker with local administrative rights on a single host capture a privileged WAC.CheckAccess token during an administrator’s portal session, craft a matching request with a forged PoP token bound to the attacker’s key, and present the two tokens to another WAC instance—effectively impersonating the privileged administrator across the tenant.

---

The exploitation chain and impact​

Preconditions for exploitation​

The vulnerability is realistic but not trivial to exploit: it requires the attacker to already possess local administrator privileges on an Azure VM or Azure Arc‑connected machine with the vulnerable WAC Azure Extension installed. From that foothold, the attacker must wait for a privileged user to connect to the target host via WAC (through the Azure Portal) and capture the WAC.CheckAccess token in that session. With those two pieces it becomes possible to impersonate that privileged user on any other WAC‑managed host in the tenant.

What a successful exploit achieves​

A successful exploit enables actions that materially change the threat model for organizations that use WAC in Azure:

• and lateral movement: The attacker can run remote commands, install extensions, and perform configuration changes on any WAC‑protected host the impersonated identity can reach. This elevates a host‑local compromise into a tenant‑level incident.
• Remote code execution (RCE): Because WAC manages remote command execution and administrative workflows, the attacker can execute code on remote VMs as the impersonated administrator.
• Stealth and audit evasion: The attack can create or use virtual UPNs (UPNs that do not correspond to real tenant users) such as patterns beginning with WAC_. Actions attributed to those virtual accounts can look legitimate in WAC logs while evading normal Azure AD user account investigations. This complicates detection and forensic trails.

Multiple independent analyses reproduce and corroborate this chain, and public CVE tracking and vendor advisories confirm the core technical facts and the vendor remediation path.

Is there evidence of active exploitation?​

At the time of public disclosure and patching, researchers reported no confirmed broad exploitation in the wild. However, multiple industry observers warned usable attack path and low barrier—given local admin access—make rapid adoption by adversaries plausible. Organizations should therefore assume potential exposure for any unpatched hosts and treat investigative actions as urgent. Where evidence is limited or unavailable, cautionary language is appropriate: absence of detection is not evidence of absence.

---

Patch, mitigate, and hunt: immediate operational guidance​

Organizations should execute a prioritized, time‑boxed response: patch, restrict, hunt, and remediate.

1. Patch first (highest priority)​

• Confirm the installed Windows Admin Center Azure Extension version Arc‑connected host that runs WAC.
• Update to Windows Admin Center Azure Extension v0.70.00 (the vendor’s fixed release). Note that some vendor pages may display variant version formatting (for example 0.70.0.0 vs 0.70.00); validate the exact package build.

Example quick checks:

• Azure CLI / PowerShell to enumerate VM extensions and versions across subscriptions.

2. Tighten network exposure (short window mitigations)​

• Restrict inbound access to the WAC API port 6516 in NSGs so that only Azure Portal gateway IP ranges and trusted admin IPs can reach it.
• Remove overly broad or permanent JIT NSG rules; if JIT is used, limit source IP ranges to the Portal gateway or specific admin ranges.
• Where possible, disable direct external IP exposure of management endpoints until patched.

3. Hunt for indicators and suspicious accounts​

Key detection signals to search for immediately:

• Logins or operations associated with virtual account UPNs that start with WAC_ (example query shown below). These UPNs are atypical and can indicate token‑based impersonation attempts.
• Access to WAC API port (6516) from unexpected IP addresses or during times when portal sessions should not exist.
• Unusual Invoke‑Command or remote PowerShell activity that originates from WAC management processes.
• Evideport or local certificate store access near suspicious WAC activity.

Example KQL to hunt in Microsoft Sentinel / Log Analytics:
DeviceLogonEvents
| where Timestamp > ago(30d)
| where AccountUpn startswith "WAC_"
| project Timestamp, DeviceName, InitiatingProcessFileName, AccountUpn, LogonType
Example PowerShell (inventory WAC Azure Extension versions):

• $vms = Get‑AzVM
• foreach ($vm in $vms) { $exts = Get‑AzVMExtension -ResourceGroupName $vm.ResourceGroupName -VMName $vm.Name; $exts | Where‑Object { $_.Publisher -like 'WindowsAdminCenter' } | Select VMName = $vm.Name, Name, Type, Publisher, Version }

4. Incident containment and remediation (if compromise suspected)​

• Isolate affected VMs from management networks and suspend WAC service network access.
• Collect forensic artifacts before any destructive remediation: Windows event logs, WAC logs, local certificate stores, and memory images.
• Rotate and revoke credentials and certificates associated with potentially impersonated identities and implicated service principals.
• Reimage or rebuild hosts where WAC service binaries, certificates, or processes show signs of replacement or tampering.
• Execute a tenant‑wide audit for lateral movement, role changes, and new service principals or role assignments.

---

Longer‑term mitigations and platform hardening​

The WAC flaw exposes a broader set of lessons for management‑pltity handling.

• Enforce strict token binding and identity matching for multi‑token authentication flows in any management plane component. Always enforce that PoP token identity claims match the access token principal.
• Reduce the number of hosts permitted to run management tooling like WAC: use dedicated, hardened jump hosts or privileged access workstations (PAWs) and avoid installing management agents on general‑purpose VMs.
• Apply the principle of least privilege for local administrators and use JIT and Just‑Enough‑Administration paradigms to minimize standing local admin rights.
• Segment and restrict management plane network access; treat management networks as separate trust zones—not general application networks.
• Integrate token binding verification checks into security code reviews and threat models for any service that accepts multiple tokens as part of an SSO handshake. rs should NOT assume
• Do not assume that standard Azure AD sign‑in logs will clearly show attacks that rely on virtual UPNs or forged PoP tokens. Actions attributed to virtual accounts may not D user and will therefore require specialized hunts.
• Do not assume patching is complete just because some hosts report updated versions; inventory and audit extension versions across all subscriptions and resource groups—extension version strings may have different formatting.
• Do not assume absence of evidence equals absence of exploitation; identity‑based attacks can blend with legitimate management traffic and require forensic confirmation.

---

Risk analysis: strengths and remaining risks​

Strengths of the response so far​

• Microsoft issued a targeted remediation (Azure Extension v0.70.00) within a short window after responsible disclosure, closing the specific token‑validation gap. Independent researchers anhed detection and mitigation guidance that defenders can operationalize immediately. These coordinated actions materially reduce the window of mass exploitability for well‑patched environments.

Remaining and residual risks​

• Unpatched hosts: Many enterprises operate aubscriptions and resource groups. Any unpatched VM or Arc host with the vulnerable extension is a continuing risk and a potential staging point for lateral movement.
• **Forenhat create or use virtual UPNs can obscure who initiated actions and make retrospective attribution difficult without deep log retention and cross‑tenant auditing.
• Operational exposure windows: JIT NSG rules and permissive management network configurations can create short windows of high exposure even in well‑patched environments—tightening these policies is essential.
• Related token‑validation issues: The WAC bug is conceptually similar to other identity plumbing problems that have recently surfaced in cloud identity systems. Teams should therefore treat WAC as part of a larger identity hardening program rather than an isolated exception.

---

Executive checklist (for immediate posting to runbooks)​

• Inventory all Azure VMs and Arc hosts for Windows Admin Center Azure Extension versions; verify none run versions older than 0.70.00.
• Patch all vulnerable hosts to the vendor fixed release immediately.
• Narrow NSG access to port 6516, remove broad JIT rules, and restrict WAC endpoint exposure until patching completes.
• Run detection hunts for Account UPNs beginning with WAC_, unusual Invoke‑Command activity from WAC processes, and certificate exports or local store reads.
• If suspicious activity is detected, isolate hosts, collect forensics before remediation, rotate affected credentials, and consider tenant‑wide audits for lateral movement.

---

Conclusion​

CVE‑2026‑20965 is a timely reminder that identity and token validation are the most critical controls in cloud management planes. A local host compromise that lets an attacker obtain or mix tokens can collapse the logical boundaries defenders rely on. Microsoft’s fix in Windows Admin Center Azure Extension 0.70.00 closes the specific exploitation path, but the fix must be deployed universally and accompanied by network hardening, credential rotation where indicated, and targeted hunts for virtual UPNs and anomalous WAC activity.
Treat this disclosure as a management‑plane emergency: patch now, tighten network exposure to WAC endpoints, hunt for the “WAC_” virtual account pattern and other forensic indicators, and prepare for tenant‑wide containment if evidence of abuse appears. The vendor patch fixes the implementation error; however, the operational work—inventory, network segmentation, least‑privilege, and persistent monitoring—must follow swiftly to restore confidence in the management plane.

---

Source: SC Media Critical Azure AD flaw in Windows Admin Center patched