A newly disclosed vulnerability in Microsoft’s Entra ID (formerly Azure Active Directory), tracked as CVE-2025-55241, could have allowed a determined attacker to impersonate any user — including Global Administrators — across nearly all Entra ID tenants, by exploiting undocumented “Actor tokens” together with improper tenant validation in the legacy Azure AD Graph API. ☠️ Security researcher Dirk-jan Mollema described it as possibly “the most impactful Entra ID vulnerability” he’ll ever find, and demonstrated that the exploit would bypass conditional access, multi-factor authentication, and generate virtually no logs in the victim tenant. Microsoft patched the vulnerability in July 2025 (rolled widely by September) after receiving Mollema’s report, and initiated further mitigations including the disabling of actor-token requests to the Graph API.
Sources: IT Pro, Hacker News
Key Takeaways
– The flaw hinged on undocumented service-to-service “Actor tokens” that were exempt from security controls like MFA, logging, and conditional access, enabling cross-tenant impersonation.
– The legacy Azure AD Graph API’s weak tenant validation allowed an actor token from one tenant to be accepted in another, enabling privilege escalation across tenant boundaries.
– Microsoft responded rapidly (within days of disclosure) and deployed global fixes, while also urging customers to migrate off the deprecated Graph API and audit privileged roles.
In-Depth
In the modern cloud world, identity systems like Microsoft’s Entra ID serve as foundational trust infrastructure: they authenticate users, grant permissions, and gate access to sensitive resources. So when there’s a flaw in that layer, anything built on top becomes vulnerable. That’s exactly what Dirk-jan Mollema discovered in mid-2025: a two-part design oversight involving “Actor tokens” and the outdated Azure AD Graph API allowed for cross-tenant impersonation that skipped nearly every security guardrail.
First, the actor tokens. These tokens were undocumented internal tokens used by Microsoft services for service-to-service (S2S) operations. Because they were designed for internal use, they avoided many of the protections placed on standard user tokens: they could bypass conditional access rules, weren’t audited in standard logs in the target tenant, and weren’t subject to revocation or usual token checks. Mollema figured out how to request such an actor token from a “lab” or benign tenant and then use it in another tenant.
Here’s where the second flaw comes in: the legacy Azure AD Graph API (graph.windows.net) failed to properly validate the “originating tenant” claim in requests. In other words, the API didn’t reliably check whether the token presented actually belonged to the same tenant it was being used against. By combining an actor token from Tenant A with a crafted request to the Graph API of Tenant B (with knowledge of a user’s netId, which can be discovered via public APIs), an attacker could impersonate a user in Tenant B — including a Global Administrator.
Mollema walked through the full sequence in his blog: obtain the tenant ID (which is publicly retrievable), determine a user’s netId, forge an impersonation token based on that, list global admins, then forge a token for one of them, and finally carry out any directory-level change or access. Because Graph API is a powerful interface, once control was gained, the attacker could create or modify identities, escalate privileges, alter policies, or pivot into Microsoft 365 / Azure.
The worst part? Very little of this triggers alerts on the victim side. Actor token issuance and use doesn’t log metadata in the target tenant, and the Graph API itself has minimal telemetry in many deployments. So unless defenders had very detailed detection rules or a strong “assume breach / hunt mode,” the attack could proceed unobserved.
Once Mollema reported the flaw to Microsoft on July 14, work started quickly. Microsoft patched the flaw in the Graph API validation logic, began blocking actor token requests for Graph, and rolled updates across their cloud systems. The official CVE-2025-55241 was published on September 4, and analysts have rated it at the maximum severity (CVSS 10.0) in Microsoft’s own reporting.
Microsoft also used the episode to push more strongly on retiring the Azure AD Graph API (which is officially being phased out), urging developers to shift to the more modern Microsoft Graph, which has improved logging, stronger validation, and better security design.
So what does this mean for organizations and for cloud security in general? At a minimum, tenants should confirm that they have received Microsoft’s fixes, verify that no residual dependencies remain on the legacy Graph API, audit privileged roles and service accounts for anomalies, and adopt threat hunting practices targeted at anomalous token use or cross-tenant telegraphing. More broadly, this incident is a stark reminder that legacy internal components—even ones hidden from public documentation—can become attack vectors, and that identity-as-a-service (IdaaS) must never be treated as invulnerable. The trust boundary that identity providers enforce must be rigorously defended and audited.