Entra ID
Azure
The CVE-2025-55241 saga: how unsigned Actor token impersonation broke tenant iso...
CVE-2025-55241 exposed a design intersection where Microsoft’s internal Actor tokens met a tenant-validation gap in the legacy Azure AD Graph API, enabling cross-tenant impersonation up to Global Admin with minimal telemetry and no Conditional Access enforcement.
The flaw allowed an attacker to request a legitimate Actor token in any tenant, craft an unsigned impersonation token, and have Azure AD Graph accept it for a different tenant when presented with that tenant’s ID and a valid user netId. Microsoft rapidly mitigated in July 2025 and formalized the CVE in September, reporting no detected abuse while urging migration away from Azure AD Graph to Microsoft Graph.
### Threat model
The trust model assumed service-to-service delegation mechanisms would stay within tightly controlled execution paths and tenant boundaries. Actor tokens, intended for backend S2S flows, conferred _“trusted for delegation,”_ enabling a service to operate on behalf of users for specific resources for 24 hours. The boundary violation occurred when Azure AD Graph accepted an unsigned, client-constructed impersonation envelope carrying a valid Actor token, without strictly binding the asserted tenant to the Actor token’s issuing [context](https://dirkjanm.io/obtaining-global-admin-in-every-entra-id-tenant-with-actor-tokens/). This shifted the effective trust anchor from verifiable, signed tokens to an unsigned wrapper, collapsing tenant isolation.
### Token anatomy
Actor tokens are standard RS256-signed JWTs from Microsoft’s legacy Access Control Service, containing audience claims for the target resource and a delegation indicator. The service that holds one can embed it in an “alg: none” impersonation token where identity is asserted via the nameid/netId tuple, rather than through another signed artifact.
The validation break was not in the Actor token itself but in the resource’s acceptance of an unsigned impersonation JWT that supplied a victim tenant ID and a valid netId from that tenant.
In effect, the resource treated the unsigned envelope as authoritative context selection, while relying on the embedded Actor token only as a capability grant, rather than as a tenant-bound proof, thereby enabling cross-tenant identity assumption.
### The role of netId/puid
The netId (surfacing as puid in access tokens) is a legacy, incremental identifier historically tied to Microsoft account plumbing and used in Entra to map identities, including B2B guests, across tenants.
Because netId values are enumerable and not cryptographically random, an attacker could feasibly discover valid netIDs for a target tenant, either by brute force or by harvesting from B2B guest attributes like alternativeSecurityIDs. Once a valid netId was known, the unsigned impersonation envelope could assert that identity inside the victim tenant while the Actor token acted as the generic capability key to Azure AD Graph.
### Why defenses didn’t engage
Conditional Access policies did not apply, because the flow never required an interactive user sign-in nor a standard signed access token minted under the victim tenant’s policy regime. Revocation could not help, because the Actor token coursed through the attacker’s tenant and the impersonation token was unsigned and constructed locally.
Telemetry was insufficient because Azure AD Graph historically lacked a comprehensive read API logging; read operations could therefore remain invisible, while write operations surfaced in audit logs with confusing principals (user UPN from the impersonation, service display names like Exchange), blending with legitimate system actions.
### Practical Attacker Sequence
An attacker would mint an Actor token in a controlled tenant, resolve the target tenant ID, and acquire a valid netId for any user in that tenant. The attacker would then construct an unsigned impersonation token pointing to Azure AD Graph for the victim tenant and issue directory queries.
From there, they could enumerate privileged roles, select a Global Admin, reconstruct a new impersonation for that principal, and perform state-changing actions such as creating users, app credentials, or role assignments. A high-leverage variant used B2B trusts to read a guest’s alternativeSecurityIds in one tenant, pivoting to the guest’s home tenant with near-zero API calls per hop, allowing exponential spread across interconnected tenants.
### Observable Traces & Hunting
Read-only reconnaissance left no artifacts in the victim tenant due to the legacy API’s limited telemetry, which is precisely why this path was so dangerous.
State changes generated audit events, but with a telltale mismatch: InitiatedBy reflected the impersonated user, while display names indicated Microsoft services, such as “Office 365 Exchange Online.”
Hunting should prioritize those anomalous combinations while excluding known, legitimate group-creation flows that do use Actor tokens on behalf of users. This signature serves more as a tripwire for past misuse than a comprehensive detector of reconnaissance.
### Remediation
Microsoft’s response severed the acceptance path by fixing Azure AD Graph’s tenant validation behavior and subsequently restricting issuance of Actor tokens for Azure AD Graph when requested via service principal credentials. Organizations should retire dependencies on Azure AD Graph in favor of Microsoft Graph, which provides superior API-level logging and policy integration.
Posture reviews should include privileged role assignments, application and service principal credentials, and recent administrative actions whose initiators align with user UPNs but bear service display names, with a particular focus on identity-plane modifications that could enable durable persistence.
### Architectural lessons
Unsigned, client-assembled impersonation envelopes create an un-auditable control surface that undermines the very purpose of signed tokens and tenant scoping.
Service-to-service delegation must preserve cryptographic binding across all layers: the resource should verify both capability and context—audience, tenant, and subject—only from signed artifacts, and reject any unsigned augmentation.
Identity-plane resources deserve first-class, comprehensive read telemetry because stealthy directory reconnaissance routinely precedes impactful attacks; absent that, defenders face “perfect-crime” conditions even when perimeter controls appear robust.
### Current State
The specific cross-tenant path under [CVE-2025-55241](https://nvd.nist.gov/vuln/detail/CVE-2025-55241) has been closed, and Microsoft reported no evidence of exploitation in the wild during its response window. The durable fix is not merely patching a legacy endpoint but tightening the delegation model: shorten token lifetimes, ensure revocability, enforce tenant-bound validation, and keep all identity-critical traffic on instrumented APIs. Security programs should treat identity-provider APIs as crown-jewel surfaces, subject to the same rigor applied to production data planes, because compromise there cascades into SaaS suites and cloud subscriptions with outsized blast radius.
