Token validation flaws in Azure WAC can break tenant isolation

At a glance

What this is: This is a vulnerability analysis showing that improper Azure AD SSO token validation in Windows Admin Center can let local admin access expand into tenant-wide compromise.

Why it matters: It matters because IAM, PAM, and cloud identity teams need to treat token binding, request scoping, and JIT exposure as enforceable controls, not trust assumptions.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

👉 Read Cymulate's analysis of CVE-2026-20965 in Azure Windows Admin Center

Context

Azure Windows Admin Center is a management plane that uses Azure AD SSO and proof-of-possession tokens to authorize remote administration of VMs and Arc-connected systems. In this case, the identity problem is not simple token theft. It is the failure of token validation, identity binding, and scope enforcement across a management path that assumes the browser, the gateway, and the target machine remain correctly aligned.

For IAM teams, the key issue is that a local machine compromise can become a cloud identity breakout if the application accepts tokens that are not tightly bound to the same user, the same request context, and the same managed resource. That turns a management session into a tenant-wide trust bridge, which is exactly the kind of hidden identity dependency that Zero Trust and least privilege are supposed to eliminate.

The article is therefore less about one vulnerable product and more about a recurring class of identity failure in cloud administration: privileged management channels often inherit trust from the surrounding platform instead of proving it on every request. That pattern is typical enough that security teams should assume similar weaknesses may exist anywhere management access crosses from local control into tenant-scoped authority.

Key questions

Q: What breaks when Azure AD SSO tokens are not tightly bound in cloud management tools?

A: The management plane can accept authorization context that does not belong to the same user, request, or resource, which lets a local foothold expand into cloud control. When token binding is incomplete, replay resistance and proof-of-possession stop being meaningful security controls and become only partial checks.

Q: Why do cloud management tools create tenant-wide risk when authorization is validated poorly?

A: They sit at the point where local admin access meets tenant-scoped authority. If the service accepts mixed identities, reused tokens, or direct access paths that bypass the intended gateway, one compromised machine can be used to reach many others inside the same tenant.

Q: What do organisations get wrong about proof-of-possession for tokens?

A: They often treat it as a narrow technical enhancement instead of a governance boundary. Proof-of-possession only works if the private key stays separated from logs, caches, and forwarding paths. If the same workflow still leaks token material, DPoP reduces replay risk but does not fix weak credential handling.

Q: Who is accountable when a management-plane flaw exposes administrative access?

A: The owning platform team and the identity governance function share accountability, because the flaw spans application design and privileged access control. Management consoles should be governed like identity infrastructure, with clear ownership for redirect policy, token handling, session design, and secure update response when flaws are found.

Technical breakdown

How Azure AD SSO token validation failed in Windows Admin Center

The flaw sits in the server-side validation of two tokens used by Windows Admin Center, a standard access token and a proof-of-possession token. In a correct design, those tokens should be bound to the same user identity, the same resource, and the same request context. Cymulate found that the implementation accepted token combinations from different users, reused tokens across requests, and ignored several contextual fields that should have narrowed authorization. That created a gap between authentication and authorization. The result was not just weaker identity assurance, but a management plane that could be convinced to treat an attacker-controlled session as legitimate.

Practical implication: enforce strict token-user-resource binding in every management workflow that uses Azure AD SSO or PoP-style controls.

Why PoP tokens did not preserve tenant isolation

Proof-of-possession is meant to stop replay by tying a token to a key pair and request details, but it only works if the server validates the full binding. Here, the browser-generated key, URL field, HTTP method, and resource identifier were not used as robust isolation boundaries. The WAC service also accepted a non-gateway path and reused the same authorization artifacts throughout the session. That means PoP became a partial check rather than an identity guarantee. Once the service accepted the wrong trust inputs, tenant isolation depended on client-side behaviour instead of server-enforced policy.

Practical implication: do not assume PoP alone is sufficient unless server-side validation proves the token is tied to the exact managed resource.

How local admin became a cloud management breakout

The attack chain begins with local administrator access on a single machine that has Windows Admin Center installed. From there, an attacker can impersonate the WAC service, capture or mix authorization artifacts, and use the resulting session to invoke management actions against other machines in the tenant. Because the service accepted invalid combinations and broad request paths, the local foothold expanded into remote command execution and lateral movement. This is a classic case of management-plane privilege amplification, where one endpoint compromise inherits the authority of the broader admin fabric. The core failure is not the endpoint alone, but the absence of tenant-wide authorization integrity.

Practical implication: treat management-plane endpoints as high-value identity assets and monitor for cross-resource administrative reuse.

Threat narrative

Attacker objective: The attacker aims to turn one local machine compromise into broad administrative control across managed Azure systems in the tenant.

1. Entry: the attacker starts with local administrator access on a Windows machine that has Windows Admin Center installed, giving them a foothold inside the management boundary.
2. Escalation: the attacker abuses token validation weaknesses and mixed token handling to obtain unauthorized cloud management access without valid Azure credentials.
3. Impact: the attacker gains remote code execution and lateral movement across other Azure VMs and Arc-connected systems in the same tenant, potentially reaching tenant-wide administrative compromise.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Tenant-wide management trust is the real attack surface here. The flaw did not merely weaken authentication on one endpoint. It allowed a local administrator on one machine to inherit authority across the tenant because the management plane trusted token context more than it verified it. That is a cloud identity governance failure, not just a product defect. Practitioners should treat management channels as identity-critical infrastructure, because a single validation gap can bypass segmentation and collapse administrative boundaries.

Proof-of-possession only works when the server enforces the whole binding. PoP is often treated as a replay protection layer, but this incident shows that incomplete validation turns it into a partial signal. The browser key, request URL, method, and token subject all mattered, yet the implementation did not require them to agree. The implication is clear: security teams cannot rely on token format alone and must inspect whether the server actually proves user, request, and resource alignment before granting privilege.

Least privilege was designed for stable, reviewable access paths, and that assumption failed here. The access model assumed a managed session would stay within its intended machine and identity boundary. That assumption breaks when the service accepts token reuse, mixed identity context, and direct access paths outside the intended gateway. The implication is not just tighter policy, but rethinking whether management-plane authorisation can still be trusted when request context is client-influenced.

Identity blast radius should be the organising concept for cloud admin controls. One compromised WAC-enabled machine should not become a launch point for tenant-wide RCE. Yet this case shows how a single identity validation flaw can amplify a local compromise into cross-resource control. The practical lesson for IAM and PAM teams is that blast radius is determined by the weakest cross-boundary check, not by the nominal privilege of the starting account.

From our research:

• 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
• That same lifecycle gap is why 52 NHI Breaches Analysis is useful when you are tracing how credential and access failures turn into breach paths.

What this signals

Identity blast radius should now be treated as a measurable design constraint for cloud administration, not an after-the-fact incident label. When a local admin foothold can expand into tenant-scoped access, the programme has already allowed management trust to exceed its intended boundary.

With 5.7% of organisations reporting full visibility into service accounts, according to the Ultimate Guide to NHIs, it is unsurprising that many teams still struggle to prove where management authority begins and ends. The practical response is to map privileged management paths as identity paths, not just network paths.

Teams that operate cloud admin tooling should expect more scrutiny of request binding, gateway enforcement, and cross-resource admin telemetry. The next control question is not whether a tool supports SSO, but whether its authorization model can survive a locally compromised endpoint without widening the tenant blast radius.

For practitioners

• Validate token-user-resource binding end to end Test whether the management service requires the same user principal, the same resource identifier, and the same request context before granting access. Simulate mixed-token combinations and confirm they fail at the server, not just at the client.
• Audit management-plane exposure for direct IP and gateway bypass paths Check whether JIT rules expose the service through both the intended gateway and the underlying network interface. If the service can be reached directly by external or VNet IP, the trust boundary is already wider than the design suggests.
• Instrument identity-based detections for anomalous admin reuse Correlate privileged access events with the machine being managed, the tenant boundary, and the historical role of the account. Alert when an identity accesses machines it has never managed before or when management actions occur without a corresponding administrative pattern.
• Treat WAC-like services as tier-zero identity assets Apply the same governance discipline used for PAM and privileged federation to management planes that can execute commands across cloud and Arc-connected systems. Review where a single endpoint compromise could expand into tenant-wide administrative reach.

Key takeaways

• This vulnerability shows that weak token validation can turn one local admin compromise into tenant-wide cloud control.
• The evidence points to a failure of user binding, request binding, and management-plane scope enforcement, not just a single authentication bug.
• Cloud and IAM teams should treat management tooling as tier-zero identity infrastructure and validate whether blast radius is truly constrained.

Key terms

• Token Binding: Token binding links a token to a specific device, certificate, or connection so it cannot be reused elsewhere without the bound proof. It reduces replay risk by making theft alone insufficient, although it does not remove the need for monitoring and revocation.
• Proof-of-Possession: Proof-of-possession binds a token or credential to a specific key so possession of the token alone is not enough to use it. For AI agents, it reduces replay risk and helps ensure that an intercepted credential cannot be reused by a different actor.
• Management-Plane Identity: A management-plane identity is any human or non-human account that can administer devices, identity providers, or security policy. These identities carry outsized risk because abuse can cascade across many systems from a single trusted account or token.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

What's in the full report

Cymulate's full blog covers the operational detail this post intentionally leaves for the source:

• The exact token fields and validation checks used by Windows Admin Center in Azure AD SSO flows.
• The exploitation walk-through showing how a local administrator can abuse the management path.
• The detection ideas for retrospective hunting across Azure logs and WAC activity.
• The updated Exposure Validation scenario used to test the vulnerability in customer environments.

👉 The full Cymulate post covers the token flow, exploitation path, and detection guidance in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.