Updated 21:10, September 18, with comment from MSRC's Tom Gallagher and further detail from Dirk-Jan Mollema.
A jaw-dropping critical Azure vulnerability tracked as CVE-2025-55241 let an attacker elevate basic privileges from their own machine to take over any Entra ID tenant globally.
The CVSS 9 bug stemmed from Microsoft’s use of undocumented backend tokens that are not subject to security policies like “conditional access” and which could be used for cross-tenant access. (Welp! Really…)
That’s according to Dutch security researcher Dirk-Jan Mollema, who reported the elevation of privilege (EOP) bug to Microsoft – which pushed a bare-bones security note out on September 4 and has quietly fixed the flaw.
"With a token I requested in my lab tenant I could authenticate as any user, including Global Admins, in any other tenant" – Outsider Security founder Mollema
He first disclosed the Entra ID vulnerability on July 14. Microsoft pushed a fix into production globally within three days and then made further mitigations on August 6, Mollema’s disclosure timeline shows.
The vulnerability, he wrote this week, “could have allowed me to compromise every Entra ID tenant in the world”. (Entra ID, previously known as Azure Active Directory, is Microsoft’s cloud-based identity management suite that lets users establish “zero trust access controls”.)

Testing exploitability, a shocked Mollema found that he could “access [any] tenant as the Global Admin, listing the users, something the guest user was not able to do”; query all Azure AD Graph API endpoints to understand everything in the tenant [and that] none of these actions would generate any logs in the victim tenant…” Yes, this is Not Good™.
What kind of backdoor craziness is this?
Microsoft described the vulnerability in its CVE note simply as an “Azure Entra Elevation of Privilege Vulnerability.” Mollema described it as stemming from “a critical token validation failure in the Azure AD Graph API” (we’ve written about Graph API exploitation before here and here.)
More fundamentally, however, it stems from Redmond’s use of so-called Actor tokens, for backend service-to-service (S2S) communication. These are unsigned JSON web tokens that let a service communicate with other services on behalf of a user; effectively impersonating a user to do so.
(Microsoft deputy CISO Naresh Kannen acknowledged the existence of their dubious architecture on July 8, saying that Redmond had “successfully mitigated more than 1,000 high-privilege application scenarios thus far” and was chipping away at more under its SFI.)
See also: Microsoft starts rotating keys again, continues sweeping security overhaul
We’ll refer to Kannen’s blog and Mollema’s write-up of CVE-2025-55241 this week for more technical details on that, but suffice to say, per Mollema, “this whole Actor token design is something that never should have existed. It lacks almost every security control that you would want:
- There are no logs when Actor tokens are issued.
- Since these services can craft the unsigned impersonation tokens without talking to Entra ID, there are also no logs when they are created or used.
- They cannot be revoked within their 24 hours validity.
- They completely bypass any restrictions configured in Conditional Access.
- We have to rely on logging from the resource provider to even know these tokens were used in the tenant.”
He told The Stack: "I had previously researched actor tokens for my Black Hat and Def Con talk, where I covered how to use them in hybrid setups for lateral movement to the cloud. While preparing my slides and proof-of-concept for the talk I tested more variants of these tokens, for different APIs and with different parameters. One of the tests I was doing was changing the tenant ID just to see if I could make them work cross-tenant.
"When that actually ended up working I had to do a few double takes and retest the whole flow to make sure I wasn’t imagining things, but the realization of the impact if this would work was quite clear from the beginning as I have researched the affected Azure AD graph API pretty closely for the past few years."
Answering our emailed questions, Mollema added: "I tested this by creating a hybrid Exchange setup, which exhibits this behaviour when communicating with the cloud. That was an entirely new authentication protocol for me, so figuring that out was some work, but once an attacker would know about this flow it would be trivial to request this token in a trial tenant."
Tom Gallagher, Vice President of Engineering at Microsoft Security Response Center told The Stack: "We appreciate the work of Dirk-Jan Mollema from Outsider Security in identifying and responsibly reporting this through a coordinated vulnerability disclosure.
"We mitigated the newly identified issue quickly, and accelerated the remediation work underway to decommission this legacy protocol usage, as part of our Secure Future Initiative (SFI). We implemented a code change within the vulnerable validation logic, tested the fix, and applied it across our cloud ecosystem. We found no evidence of abuse of this vulnerability, and to maintain transparency, we issued a no-action CVE-2025-55241.
He added: We remain committed to strengthening our identity standards, driving adoption through the usage of standard SDKs across 100% of applications, while continuing our work with the community to responsibly identify and remediate vulnerabilities, improving security for all.”
We keep our security stories free out of public interest reasons. Joining our paid tier also gets you access to exclusive events and in-depth interviews with leading CIOs, CISOs and other technology budget-holders doing dirty, dangerous and difficult work in the trenches.