Understanding the CVE-2025-55241 Vulnerability in Microsoft Entra ID
In September 2025, a critical vulnerability known as CVE-2025-55241 was disclosed, revealing significant weaknesses in Microsoft Entra ID, previously known as Azure Active Directory (Azure AD). This flaw poses a serious security risk, allowing attackers to impersonate Global Administrators across nearly any Entra ID tenant. The implications of this vulnerability extend to Microsoft 365, Azure resources, and associated applications, all operating without detection.
The Core of the Vulnerability
Experts categorize this vulnerability as one of the most severe issues identified in Entra ID. It stems from a misuse of undocumented Actor tokens and a fundamental design flaw in the Azure AD Graph API. This interface, despite being a legacy system, is still heavily utilized by many internal Microsoft services.
What Are Actor Tokens?
Actor tokens are a specific type of JSON Web Token (JWT) issued by Microsoft’s Access Control Service. Their primary function is to facilitate communication between services, particularly for Microsoft’s applications like Exchange Online and SharePoint.
What makes Actor tokens particularly alarming is their lack of regulation. They are not subject to Conditional Access policies, do not provide real-time telemetry, and are never logged in the target tenant. Valid for 24 hours, these tokens include a “trustedfordelegation” claim that enables the bearer to impersonate any user, including Global Admins, without the tenant’s awareness.
Furthermore, the tokens can be embedded within client-side constructed impersonation tokens, which successfully pass verification checks. Notably, these impersonation tokens are unsigned, eliminating any cryptographic protection. As a result, they can be submitted to the Azure AD Graph API without facing challenge.
The Azure AD Graph API Flaw
The true gravity of this vulnerability lies in the flaws associated with the Azure AD Graph API. During security assessments conducted in anticipation of conferences like DEF CON and Black Hat, researchers discovered that the API failed to validate the tenant ID of incoming impersonation tokens. This oversight enabled attackers to exploit the vulnerability in multiple ways:
- An attacker could utilize an Actor token from a controlled tenant.
- They could create a token impersonating users from other tenants.
- Following this, they could submit requests to the Azure AD Graph API as any user, thereby accessing or modifying data as if they were that user, including those with Global Admin privileges.
This breach effectively undermines the fundamental principle of tenant isolation in multi-tenant cloud platforms.
Untraceable Access and Data Theft
One of the intriguing aspects of this vulnerability is the complete absence of telemetry associated with the exploit:
- The issuance of Actor tokens goes unlogged.
- Impersonation tokens remain unsigned and unverified during runtime.
- The Azure AD Graph API does not generate logs for read operations.
While some actions, such as user creation or configuration changes, might produce audit logs, these actions often appear as though executed by legitimate Global Admins. This lack of visibility results in nearly undetectable exploitation.
Data accessible via this vulnerability includes:
- User profiles and personal information.
- Group memberships and roles.
- Tenant configurations along with Conditional Access policies.
- Application settings and crucial BitLocker recovery keys.
Proof of Concept and Exploit Flow
The researcher also provided a proof of concept that outlined minimal prerequisites for exploiting this vulnerability. The key requirements included:
- Access to a tenant ID, which can be publicly obtained.
- A netId, which is a legacy identifier present in access tokens.
With these, an attacker can impersonate any user and escalate privileges to Global Admin level, thereby performing reconnaissance or establishing a persistent foothold without raising alarms.
The exploitation can be particularly effective in environments utilizing B2B trust relationships. When a user from Tenant B is invited to Tenant A, their netId is stored in Tenant A. An attacker with access to Tenant A could then extract this netId to impersonate the user in their home tenant (Tenant B). The default settings of Entra ID make it feasible to repeat this across multiple tenants, including Microsoft’s own, due to guest accounts and cross-tenant relationships.
Timeline and Microsoft’s Response
The vulnerability was responsibly disclosed to Microsoft on July 14, 2025. Following this, Microsoft embarked on an investigation and implemented a global fix by July 17, with additional mitigations introduced on August 6. The official assignment of CVE-2025-55241 took place on September 4, complemented by the publication of full technical details on September 17.
In response, Microsoft took several steps, such as:
- Blocking the use of Actor tokens across tenants via Azure AD Graph.
- Restricting Actor token issuance with Service Principal credentials.
- Reporting that no exploitation was detected, although this does carry caveats given the exploit’s stealthy nature.
Detection and Defense Methods
While Azure AD Graph’s read operations remain unlogged, researchers have developed detection methods focusing on anomalies within audit logs for write operations. For example, logs showing a user’s User Principal Name (UPN) alongside an application’s display name (e.g., “Exchange Online”) could indicate misuse of Actor tokens.
A sample Kusto Query Language (KQL) detection rule can filter for suspicious operations initiated by services such as SharePoint, Dynamics, or Exchange that appear under Global Admin accounts—an indicative sign of token-based impersonation.
By keeping a close watch on these metrics, organizations can better safeguard against the threats posed by vulnerabilities like CVE-2025-55241, thereby protecting their digital assets and sensitive information.