CVE-2026-20965: Is Your Windows Admin Center Still Exposed to Tenant-Wide RCE
CVE-2026-20965 is a high-severity flaw (CVSS 3.1 base score 7.5) in Windows Admin Center’s Azure AD single sign-on implementation, patched in the Windows Admin Center Azure Extension version 0.70.00. If you’re running Windows Admin Center against Azure VMs or Arc-connected servers and haven’t confirmed your extension version since early this year, this is worth checking today, the impact if you’re still exposed is genuinely severe.
We don’t run Windows Admin Center in our own lab, so this post is research and citation-based rather than a lab reproduction, the version-check script below is accurate and safe to run against your own environment, it just wasn’t captured as a screenshot from our own infrastructure.
What actually went wrong
Windows Admin Center’s Azure SSO lets you sign into the management portal once with your Azure AD identity and have that session extend across Azure VMs and Arc-connected machines in your tenant, convenient for managing a fleet without re-authenticating against each box individually. The vulnerability sits in how that SSO implementation validated two tokens involved in the handshake: a privileged access token and a Proof-of-Possession (PoP) token meant to prove the holder legitimately controls the credential, not just possesses a copy of it.
Security researchers at Cymulate Research Labs found that these tokens weren’t being cross-validated correctly, which meant an attacker could pair a stolen privileged token with a separately forged PoP token to impersonate a legitimate user to the SSO flow. Critically, the starting point for this wasn’t some remote network exploit, it was local administrator access on a single managed machine. From there, the flaw let an attacker pivot outward to other Windows Admin Center managed Azure VMs and Arc-connected systems across the entire tenant, without ever needing valid Azure credentials of their own for those other machines.
That’s the part that makes this more than a routine local-privilege bug: a single compromised endpoint with local admin rights (via malware, a misconfigured service, a stolen local account, anything) becomes a credible path to tenant-wide lateral movement and remote code execution across every other machine Windows Admin Center is managing in that Azure AD tenant.
Who’s actually affected
Every Azure virtual machine or Arc-connected system managed through Windows Admin Center’s Azure SSO extension, running a version of that extension older than 0.70.00. This specifically concerns the Azure Extension component of Windows Admin Center (the piece enabling Azure AD SSO and Azure-integrated management), not every Windows Admin Center deployment in general, if you’re running WAC purely on-prem without the Azure extension enabled, this particular flaw doesn’t apply to you the same way, though keeping WAC itself current is still good practice regardless.
Step 1: check your Windows Admin Center Azure Extension version
From the Windows Admin Center gateway itself, the extension version is visible under Settings > Extensions, look for the “Azure” extension in the installed list and confirm its version is 0.70.00 or newer. For checking across a fleet without opening the UI on every gateway, this PowerShell approach reads the extension manifest directly from a WAC gateway’s installation folder:
# Run on the Windows Admin Center gateway server itself
$wacPath = "C:\Program Files\Windows Admin Center"
Get-ChildItem -Path $wacPath -Recurse -Filter "Microsoft.WindowsAdminCenter.Azure*.dll" -ErrorAction SilentlyContinue |
Select-Object Name, @{N="Version";E={$_.VersionInfo.FileVersion}}, DirectoryIf you manage Windows Admin Center gateways centrally, cross-reference the result against your deployment’s known-good baseline rather than relying on a single gateway’s check as representative of your whole fleet.
Step 2: update the extension
From the Windows Admin Center gateway, go to Settings > Extensions > Available extensions, find Azure, and install the update (0.70.00 or later). If your gateway doesn’t have direct internet access, Windows Admin Center supports offline extension updates via a downloaded package, check Microsoft’s extension management documentation for that workflow if you’re in a disconnected or air-gapped environment.
Step 3: review what local admin accounts actually exist on your managed machines
Since the attack’s entry point is local administrator access on any one managed machine, patching the extension closes this specific flaw, but it’s also a good prompt to audit how many accounts actually hold local admin rights across your Windows Admin Center-managed fleet. Fewer standing local admin accounts means fewer potential entry points for this class of attack in general, independent of this specific CVE.
Quick guide
- Check your Windows Admin Center Azure Extension version from Settings > Extensions, or script it across your gateways.
- If it’s older than 0.70.00, update it from the same Extensions page.
- Confirm the update applied by re-checking the version.
- Use this as a prompt to review local admin account sprawl on your WAC-managed machines generally.
FAQ
Does this affect Windows Admin Center if I’m not using the Azure extension?
The specific flaw is in the Azure AD SSO implementation delivered through the Azure Extension component. If you run Windows Admin Center entirely on-premises without that extension enabled, you’re not exposed to this specific vulnerability, though keeping any Windows Admin Center deployment patched is still worthwhile practice on its own.
Does an attacker need valid Azure credentials to exploit this?
No, that’s what makes it serious. The documented attack path starts from local administrator access on a single managed machine, not from stolen Azure credentials. The flaw itself is what let that local foothold translate into tenant-wide reach without ever needing a legitimate Azure sign-in to the other machines.
Is there a workaround if I can’t patch immediately?
The vendor-recommended fix is updating to Azure Extension 0.70.00 or later, there’s no documented standalone mitigation that fully closes this without the update. In the meantime, minimizing standing local administrator accounts on WAC-managed machines reduces your exposure to the attack’s entry point, though it doesn’t eliminate the underlying token validation flaw.
How would I know if this was already exploited against my environment?
Review Windows Admin Center gateway logs and Azure AD sign-in logs for unexpected cross-machine session activity or sign-ins from the WAC service identity that don’t correspond to a legitimate admin action you recognize. If you suspect active exploitation rather than just unpatched exposure, treat it as a real incident and involve your security team rather than just applying the patch and moving on.
