CVE-2026-69836 

The vulnerability stems from an unsafe deserialization of untrusted data, a class of flaw where an application reconstructs objects from attacker-supplied input without first validating it. 

Because Entra ID is a cloud-hosted service, Microsoft was able to remediate the vulnerability on the server-side, meaning customers did not need to install any patches.  

The disclosure itself became an unusual story. Microsoft initially marked the vulnerability as “Exploited: Yes” in its advisory, leading to widespread reports that the flaw was under active attack. However, the company reversed this designation the following day to “No” without a detailed public explanation. Microsoft later clarified that the change was informational and that there was no confirmed exploitation in the wild. 

Quick overview: 

Vulnerability: Deserialization of Untrusted Data (CWE-502) in Microsoft Entra ID. 

Impact: Allows an unauthenticated attacker to execute remote code over a network, which could lead to a complete compromise of the identity service. 

CVSS Score: 10.0 (Critical). The vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, indicating it’s exploitable over the network with low complexity, no privileges, and no user interaction. 

Status: Microsoft has fully mitigated the vulnerability on its infrastructure. No patch is required from customers. Crucially, Microsoft has corrected its initial advisory to state that there is no evidence of active exploitation in the wild. The initial “Exploited: Yes” flag was a mistake. 

Takeaway for Threat Hunters: Because the vulnerability was server-side and already fixed, hunting should focus on detecting anomalous, suspicious, or unauthorized activities within Entra ID that could be indicative of an attacker leveraging this flaw before it was patched. The goal is to identify any lingering signs of compromise. 

KQL Queries for Threat Hunting 

The following KQL queries are designed to help you hunt for potential post-exploit activity in your Microsoft Entra ID tenant. 

1. Hunt for Suspicious Service Principal Activity 

Attackers gaining code execution could manipulate service principals and their credentials to maintain persistence. 

Hunt for unusual service principal credential additions or modifications 

AuditLogs
| where OperationName in ("Add service principal credentials", "Add service principal", "Update service principal")
| where TimeGenerated > ago(XXd) // Adjust the time range as needed
| project TimeGenerated, OperationName, ActorDisplayName, TargetDisplayName, TargetResources, Result
| order by TimeGenerated desc

This query looks for the creation or modification of service principals and their credentials. A sudden surge or creation by a non-administrative user could be a sign of compromise. This is a critical area to monitor because persistence through service principals is a common attacker technique. 

In Microsoft Entra ID audit logs, operations track the creation, modification, and credential management of service principals (the local instance of an application object in a specific tenant). 

Add service principal 

A new service principal object was created in your directory. 

This happens when an application from the Microsoft Entra application gallery is added, an application is registered/instantiated in the tenant, or a managed identity is created. 

Add service principal credentials 

A new authentication credential such as a password/secret or a public certificate was added to an existing service principal. 

This is often logged as part of an Update service principal activity. Attackers frequently target this operation to maintain persistent, programmatic access to a compromised environment without needing a user account. 

Update service principal 

General properties or configurations of an existing service principal were modified. 

This includes changing settings like assignment requirements, homepage URLs, owners, or enabling/disabling the service principal. It also frequently acts as the parent operation category when credentials or role assignments are added 

2. Investigate Unusual and High-Risk Sign-ins 

Look for sign-in events with high risk levels or from unusual locations, especially from accounts with high privileges. 

Find high-risk sign-ins or sign-ins from unfamiliar locations/IPs 

SigninLogs
| where TimeGenerated > ago(XXd) // Adjust the time range as needed
| where RiskLevelDuringSignIn in ("high", "medium") // Adjust risk level as needed
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, RiskLevelDuringSignIn, RiskEventTypes
| order by TimeGenerated desc

This query identifies sign-ins that Microsoft’s risk engine has flagged as high or medium risk. While the vulnerability itself is server-side, any successful exploitation could lead to token theft or account takeover for a specific user. Investigating these risky sign-ins can uncover such activity. 

3. Monitor for Anomalous Privileged Role Assignments 

Check for any unauthorized or unusual changes to privileged roles, which could be the final stage of an attack to gain control. 

Detect any new additions to highly privileged roles 

AuditLogs
| where OperationName == "Add member to role"
| where TimeGenerated > ago(XXd) // Adjust the time range as needed
| extend Role = tostring(parse_json(TargetResources)[0].displayName)
| where Role in ("Global Administrator", "Privileged Role Administrator", "Exchange Administrator", "Conditional Access Administrator")
| project TimeGenerated, Role, TargetUser = tostring(parse_json(TargetResources)[0].modifiedProperties[1].newValue), Result
| order by TimeGenerated desc

This query specifically monitors for membership additions to high-privilege roles within the last XX days. Any unexpected addition to these roles is a significant red flag and should be investigated immediately. 

Role Details in Microsoft Entra ID: 

Global Administrator: Has access to all administrative features and tenant-wide settings in Microsoft Entra ID. 

Privileged Role Administrator: Can manage role assignments, audit logs, and role definitions in Microsoft Entra ID. 

Conditional Access Administrator: Can manage Conditional Access policies and settings within Microsoft Entra ID. 

Exchange Administrator: Can manage all aspects of the Exchange organization, available as an integrated role assignable through Microsoft Entra ID or the Exchange admin center. 

Recommended Next Steps for Incident Response 

1. Review Entra ID Audit and Sign-in Logs: Focus on the period before August 20, 2026 (the NVD published date and the date Microsoft first disclosed the flaw), as this is when the vulnerability was unpatched and potentially exploitable. Look for any of the anomalies identified in the queries above. 

2. Enforce Least Privilege: Review all privileged accounts and ensure they adhere to the principle of least privilege. Use Privileged Identity Management (PIM) to enforce just-in-time access. 

3. Strengthen Conditional Access Policies: Re-evaluate and enhance Conditional Access policies to block sign-ins from risky or unfamiliar locations. 

4. Stay Informed: Monitor (CVE), official Microsoft communications (MSRC), CISA Known Exploited Vulnerabilities (KEV) catalog and NIST National Vulnerability Database (NVD). 

Want to learn more?

Join our FREE live webinar:

Uncovering New Identity Theft Vectors and How to Mitigate Them

Discover how identity theft no longer begins and ends with a stolen password.

Paula Januszkiewicz (CEO of CQURE and CQURE Academy, Cybersecurity Expert & Red Teamer, Microsoft Regional Director, MVP, and MCT) will unveil new identity attack paths, including original research from the CQURE Team demonstrating how an attacker can move from endpoint access to cloud identity takeover, compromise sensitive user secrets, gain access to protected resources such as KeePass, and evade traditional EDR/XDR visibility.

Register for free:
👉 https://luma.com/TheftVectors