A couple of weeks ago, a security researcher named Dirk-jan Mollema discovered something that should make every Entra ID administrator sit up straight in their chair: a flaw that could have allowed anyone to become a Global Admin in literally any Entra ID tenant in the world. No phishing required. No stolen passwords. No insider access. Just a few API calls and some brute force work.
Two things about this issue make it particularly sobering: first is that the vulnerability received a rare 10.0 severity score (more on that in a moment), but perhaps more importantly, it went undetected throughout Microsoft’s entire Secure Future Initiative‚ which I recently wrote about.
Serendipitous Discovery, Terrible Implications
Mollema, a well-known security researcher and the creator of the widely used ROADtools security tools, stumbled onto the vulnerability that came to be known as CVE-2025-55241 in July 2025 while preparing for his Black Hat and DEF CON presentations. He was investigating hybrid Exchange setups, specifically how Exchange uses something called the Access Control Service for backend authentication, when he decided to experiment with “actor tokens” in his lab environment. Actor tokens, it turns out, are an undocumented authentication mechanism Microsoft uses for service-to-service communication. They’re relics from the Microsoft Account (MSA) legacy codebase, issued by a service that was officially retired back in 2018 but apparently still lurking in production. These tokens have some remarkable properties, none of them good from a security perspective:
- There’s no logging when they’re issued
- There’s no logging when they’re used
- There’s no revocation mechanism
- They bypass all conditional access policies
After discovering that actor tokens exist, Mollema did what any good researcher does: he started poking at edge cases. He changed the tenant ID in an impersonation token from his own lab tenant to a completely different tenant where his test accounts didn’t exist. Instead of the expected “access denied” error, he got a message indicating the token was accepted, but the identity couldn’t be found in that tenant.
That’s when he realized he’d found something extraordinary. In his own words, this was “the most impactful Entra ID vulnerability that I will probably ever find.” He wasn’t exaggerating.
How the Vulnerability Actually Worked
The vulnerability combined two critical components. First, the actor tokens themselves are wrapped inside an unsigned JSON web token (JWT), which also contains a user identifier called a “netId,” which is leftover from the original Microsoft account (MSA) codebase. Second, Azure AD Graph API failed to properly validate that the tenant ID field of the actor token matched the tenant being accessed. That means that you could request an actor token in your own tenant, then present it to any other tenant, and the Azure AD Graph API would happily accept it. The actual attack depended on one additional thing: a valid netId for a user in the target tenant. As it happens, netIds aren’t created with a random-number generator like GUIDs, they’re created as incremental identifiers. Mollema estimated that it would be possible to brute-force netIds in “minutes to hours” because of the relatively small sequence number differences between them– and because actor token access doesn’t generate logs, brute force attempts wouldn’t trigger alerts in the victim tenant. Once you have a netId for a valid user—and in this case, that user could be a global admin or other privileged account, presenting the actor token was enough to impersonate that user. Because the actor token isn’t signed, there’s no way for Microsoft to easily detect that the token’s been tampered with.
Maximum Impact
CVSS scores measure the impact, complexity, and difficulty of attacks using a standardized scoring system. The higher the score, the worse the vulnerability. This particular vulnerability originally received a CVSS score of 9.0 but was quickly upgraded to 10.0, the maximum possible rating. Microsoft later argued this downward to 8.7-9.0, arguing that the attack complexity should be rated as “High” because it requires “measurable effort” to identify netIds. The security community largely disagreed with this downgrade, pointing out that brute forcing incremental identifiers hardly qualifies as “high complexity.” In fact, Heather Adkins, vice president of security engineering at Google, said it’s “one of the worst vulns I’ve ever seen.”
The CVSS score doesn’t really capture how bad this vulnerability is, though. Impersonating a regular user would allow an attacker to read all the user, group, and role assignment data from the target tenant and see some tenant and conditional access policies. However, impersonating a privileged account would allow the attacker to completely take over the tenant, including taking ownership of Azure subscriptions, modifying security policies, modifying logging settings, and changing or modifying application access credentials. In both cases, the attacker could also use the ability to sign into Entra to pivot to other third-party SaaS applications configured to use Entra ID SSO.
Because actor token access isn’t logged, you wouldn’t see any signs of reconnaissance, unless and until the attacker actually changed something. Since the attacker could choose any account to impersonate, you might not have even noticed the changes if they appeared to be made by an authorized account.
Microsoft’s Response
To Microsoft’s credit, they moved quickly once Mollema reported the vulnerability. He reported the vulnerability on 14 July, and Microsoft had fixed it by 17 July. However, the CVE wasn’t issued until 4 September, and Mollema didn’t provide a full disclosure until 17 September. This is not an unreasonable timeline, since Microsoft needed time to investigate internally and ensure they had truly fixed the problem before going public. Since the CVE issuance, they have been pretty quiet, though.
Tom Gallagher, VP of Engineering at Microsoft Security Response Center, provided an official statement (quoted here): “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).” However, Gallagher didn’t give any details on how this enormous vulnerability wasn’t noticed before, given that the SFI has been going on for a while now.
Microsoft’s actual fix included three changes. First, they added code changes in the Azure AD Graph API to properly validate the originating tenant of actor tokens. Second, they blocked applications from requesting actor tokens for the Azure AD Graph API entirely. Third, they accelerated the deprecation timeline for the Azure AD Graph API. (It’s arguable that they should have done all of these things earlier, but that’s a discussion for another time.)
What should you do?
Although Microsoft said administrators don’t have to take any action, I don’t buy it.
At a minimum, you should do the following:
- Use the KQL query in Mollema’s blog post to look for potential exploits of this vulnerability prior to 17 July 2025. Because of the aforementioned lack of logging, you may not see anything. Don’t let that make you complacent.
- Look for unusual or inexplicable privilege escalation attempts or inappropriate use of privileges. I’d suggest paying special attention to changes to conditional access policies, creation of privileged accounts, or changes to application credentials.
- If you’re using Azure AD Graph API anywhere, quit using it and move to Graph.
- Ensure that you have proper logging and a SIEM if you need it, to catch things like impossible travel and repeated authentication failures.
What Remains Unknown
Microsoft says its internal telemetry shows no evidence that this vulnerability was exploited in the wild before the fix was deployed. However, since there’s no logging when actor tokens are used, how would they know? As Roei Sherman of Mitiga Security pointed out, “the lack of historical visibility means defenders still can’t be sure whether it was used in the past.”
Of course, the bigger unknown is how this vulnerability slipped through the Secure Future Initiative, which is supposed to be dedicating tens of thousands of man-years specifically to fixing this exact sort of problem—but was discovered accidentally by an outside researcher. Given that the problem has survived the entire tenure of SFI so far, this is not reassuring. Moving off Entra ID isn’t a realistic possibility for most of us, so we’ll have to stay vigilant and continue to press Microsoft to do better.
