While preparing for my Black Hat and DEF CON talks in July of this year, I found the most impactful Entra ID vulnerability that I will probably ever find. This vulnerability could have allowed me to compromise every Entra ID tenant in the world (except probably those in national cloud deployments). If you are an Entra ID admin reading this, yes that means complete access to your tenant. The vulnerability consisted of two components: undocumented impersonation tokens, called “Actor tokens”, that Microsoft uses in their backend for service-to-service (S2S) communication. Additionally, there was a critical flaw in the (legacy) Azure AD Graph API that failed to properly validate the originating tenant, allowing these tokens to be used for cross-tenant access.
Effectively this means that with a token I requested in my lab tenant I could authenticate as any user, including Global Admins, in any other tenant. Because of the nature of these Actor tokens, they are not subject to security policies like Conditional Access, which means there was no setting that could have mitigated this for specific hardened tenants. Since the Azure AD Graph API is an older API for managing the core Azure AD / Entra ID service, access to this API could have been used to make any modification in the tenant that Global Admins can do, including taking over or creating new identities and granting them any permission in the tenant. With these compromised identities the access could also be extended to Microsoft 365 and Azure.
I reported this vulnerability the same day to the Microsoft Security Response Center (MSRC). Microsoft fixed this vulnerability on their side within days of the report being submitted and has rolled out further mitigations that block applications from requesting these Actor tokens for the Azure AD Graph API. Microsoft also issued CVE-2025-55241 for this vulnerability.
Impact
These tokens allowed full access to the Azure AD Graph API in any tenant. Requesting Actor tokens does not generate logs. Even if it did they would be generated in my tenant instead of in the victim tenant, which means there is no record of the existence of these tokens.
Furthermore, the Azure AD Graph API does not have API level logging. Its successor, the Microsoft Graph, does have this logging, but for the Azure AD Graph this telemetry source is still in a very limited preview and I’m not aware of any tenant that currently has this available. Since there is no API level logging, it means the following Entra ID data could be accessed without any traces:
User information including all their personal details stored in Entra ID.
Group and role information.
Tenant settings and (Conditional Access) policies.
Applications, Service Principals, and any application permission assignment.
... continue reading