TL;DR: A token validation flaw in Azure Windows Admin Center let an attacker with local admin on one machine bypass identity checks, execute remote code, and move laterally across Azure VMs and Arc-connected systems in the same tenant, according to Cymulate Research Labs. The failure shows how scoped tokens and proof-of-possession controls collapse when user binding, request binding, and gateway assumptions are not enforced.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Cymulate's research: Improper Azure WAC token validation in CVE-2026-20965 can collapse tenant isolation and enable remote code execution across managed machines.
Why it matters: IAM and cloud security teams need to treat token binding, request scoping, and gateway trust as enforceable controls, not assumptions, when admin workflows cross VM and tenant boundaries.
Context
A token validation flaw in Azure Windows Admin Center shows how cloud management planes can fail when identity tokens are treated as interchangeable across machines and requests. In this case, the security boundary depended on user binding, resource binding, and gateway validation all holding at once.
For identity programmes, the issue sits at the intersection of privileged access, federated sign-in, and workload-adjacent administration. The operational lesson is straightforward: when a management service accepts tokens that are not tightly bound to the user, request, and resource, tenant isolation becomes brittle.
Key questions
Q: What breaks when Azure WAC accepts token pairs that are not bound to the same user?
A: The server can no longer prove that the caller who presents a valid access token is the same principal that owns the PoP context. That breaks the authorization chain and lets an attacker combine token material across identities, which can turn local access into tenant-level management access.
Q: Why does direct access to a management gateway increase the impact of token validation flaws?
A: Because direct reachability gives an attacker more than one path to exercise the flaw, including rogue service impersonation and token replay against the management plane. When the intended gateway path is bypassed, the service has to be right every time, and any validation gap becomes an exploitation path.
Q: How can IAM teams tell whether proof-of-possession is actually protecting a service?
A: Check whether the service verifies the full binding set, including user identity, request context, resource identifier, and nonce handling, on every request. If any of those fields can be ignored, reused, or mixed across sessions, possession proof is only partially enforced and cannot be trusted as the sole control.
Q: What should teams do after a tenant-isolation failure in a privileged admin plane?
A: Treat the event as a control-plane compromise, review all access paths that reached the service, and validate whether tokens, gateway exposure, and administrative roles were overbroad. The priority is to contain cross-boundary access first, then assess whether the same validation pattern exists elsewhere in the environment.
Technical breakdown
How Azure WAC token binding is supposed to work
Azure Windows Admin Center uses a normal access token for authorization and a proof-of-possession token to bind the request to a browser-generated key. In principle, the first token proves the user has access and the second proves the caller holds the matching private key, while request fields such as URL and resource ID narrow where that token can be used. That model only works if the server validates all bindings together and rejects mismatches between identity, request context, and resource scope. When any one of those checks becomes advisory instead of mandatory, the token pair stops being a trust boundary and becomes a reusable authorization artifact.
Practical implication: Treat token binding as a server-side enforcement problem, not a client-side assurance pattern.
Why UPN mismatch and reused session tokens break tenant isolation
The flaw described by Cymulate arises because the server did not enforce that the user principal name in the access token matched the PoP token context, and it reused the same tokens across requests. That creates a mix-and-match condition in which a valid access token from one identity can be paired with a different PoP token, weakening the intended proof that the request came from the right user and session. Once the service accepts that combination, access scope becomes decoupled from the original authentication event, and tenant boundaries start to depend on field-level validation rather than identity assurance.
Practical implication: Validate user identity, nonce, method, and resource binding on every request path that accepts federated tokens.
How direct WAC exposure turns a validation flaw into lateral movement
The article also shows that JIT exposure of the WAC port and direct connectivity through network paths widened the attack surface. If a management interface is reachable outside the intended gateway path, an attacker with local administrator access can position a rogue service, harvest or replay the right token material, and target other WAC-managed machines in the tenant. The issue is not only token weakness but also the architectural assumption that the portal path remains the exclusive control plane. When that assumption fails, the service becomes a cross-boundary pivot point for remote code execution and tenant-wide movement.
Practical implication: Restrict management-plane reachability so token validation failures cannot be paired with direct network access.
Threat narrative
Attacker objective: The objective is to break out of one managed machine and gain remote command execution across other WAC-managed assets in the tenant.
- Entry occurs when an attacker already has local administrator access on a WAC-managed Azure VM or Arc-connected machine.
- Credential access and abuse follow when the attacker leverages the WAC Azure SSO flow to obtain or mix valid token material without holding Azure credentials.
- Escalation happens when the server accepts mismatched identity and PoP context, allowing the attacker to impersonate a privileged admin session.
- Impact is tenant-wide remote code execution and lateral movement across other WAC-enabled systems in the same tenant.
Breaches seen in the wild
- ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Scoped token trust collapses when request binding is incomplete: The control assumption in this case is that a valid token pair stays tied to one user, one request, and one resource. Cymulate’s finding shows that assumption breaks when the server accepts reused tokens and ignores identity mismatches. The practical conclusion is that authorization quality depends on server-side binding fidelity, not on token sophistication alone.
Tenant isolation is only as strong as the weakest management-plane hop: Azure WAC is not a simple admin UI here, it is a privileged control plane that can bridge local admin access into tenant-wide action. When a management workflow exposes direct connectivity and then tolerates weak token validation, the tenant boundary becomes procedural rather than cryptographic. Practitioners should treat management-plane reachability as part of identity design, not just network design.
Proof-of-possession does not compensate for broken identity correlation: PoP controls were built to reduce replay and token theft, but that protection assumes the server checks what the client claims to be. If the access token, PoP wrapper, URL, and user identity are not correlated, PoP becomes a partial control that can be bypassed through combination attacks. For IAM teams, the lesson is that possession proofs do not rescue a service that cannot reliably tie the proof to the right principal.
Gateway assumptions matter as much as token format: The article shows that direct access to the WAC service and JIT-opened ports widened the exploit path beyond the intended portal flow. That means the threat was not just a validation bug, but a broken trust model for where the request is allowed to originate. The field takeaway is to align gateway design, network exposure, and identity validation as one control surface.
What this signals
Identity binding has to survive the full request path: This incident shows why token validation cannot be treated as a front-door check. When user identity, request context, and resource scope are not locked together at the service boundary, privileged admin paths become reusable across machines and tenants.
A second programme risk is over-reliance on gateway architecture as a compensating control. If the management plane can be reached directly or through temporary openings, then the identity layer has to withstand hostile use on its own, which many admin flows are not designed to do.
For practitioners
- Enforce per-request identity correlation Verify that the subject in the access token, the PoP token context, and the target resource all match on every request, including method and nonce handling.
- Restrict management-plane exposure Limit WAC reachability to the intended gateway path and remove direct access paths that let a server be contacted outside the portal-mediated flow.
- Test for token mix-and-match abuse Replay valid token pairs across different user contexts and resource identifiers to confirm the server rejects mismatched UPN and resource binding.
- Review JIT openings on admin ports Confirm that temporary access rules do not expose the WAC API broadly enough to support direct exploitation from the network edge.
Key takeaways
- The flaw was not just token weakness, but a broken trust model that let local admin access become tenant-wide remote code execution.
- Cymulate’s analysis shows how mismatched user binding and reusable token context can undermine Azure WAC isolation guarantees.
- The control gap is server-side correlation of identity, request, and resource. Without that, management-plane tokens become transferable attack material.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The flaw is an authentication validation failure in Azure WAC SSO and PoP handling. |
| NHI-08 — Environment Isolation | The exploit breaks tenant and machine isolation across WAC-managed systems. | |
| Recommendation — Harden token validation so identity, resource, and request context are enforced together on every call. Separate management-plane trust boundaries so one compromised host cannot pivot across tenant scope. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Identification and Authentication (Service and Organization Users) | WAC is authenticating a service-adjacent management flow where token lifecycle and binding matter. |
| Recommendation — Apply IA-9 to verify service-authenticated requests are bound to the correct identity and context. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is an authorization failure that lets access exceed the intended tenant scope. |
| Recommendation — Use PR.AA-05 to limit admin entitlements to the exact machine and action scope required. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attacker abuses token material to access credentials and move across the tenant. |
| Recommendation — Map token abuse to TA0006 and TA0008 to improve detection of cross-boundary movement. | ||
Key terms
- Proof Of Possession Token Binding: A control that ties a token to the client that originally obtained it, so the token is not useful if stolen and replayed elsewhere. In OAuth environments, this reduces the value of intercepted credentials and is especially relevant for autonomous API clients and AI agents.
- 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.
- Tenant Isolation: Tenant isolation is the practice of separating identities, tokens, sessions, logs, and data so one tenant cannot access another tenant's resources. It can range from full physical or logical separation to carefully controlled shared services with strict tenant-aware policy enforcement.
- Management Plane: The administrative layer used to configure, govern, and enforce behaviour across many endpoints or services. A management plane is not the workload itself. It is the control layer above it, which makes it especially sensitive to privileged misuse and delegated automation.
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 IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org