CVECVE-2026-69836
CVSS 10.0
TypeDeserialization RCE
CWE-502
Unauthenticated
PatchedServer-side by
Microsoft before
disclosure
Customer actionNone required
for patching
ExploitationConfirmed in wild
No timeline/actor
disclosed
What happened
Microsoft disclosed CVE-2026-69836 on August 20, 2026, confirming that the vulnerability had already been exploited in the wild and that Microsoft had already deployed the fix to Entra ID's infrastructure before public disclosure. The vulnerability is a deserialization of untrusted data flaw classified under CWE-502 in Microsoft Entra ID, the cloud-based identity and access management platform formerly known as Azure Active Directory. Entra ID is the authentication and authorization backbone for Microsoft 365, Azure services, and any third-party application that uses Entra for single sign-on or OAuth integration. The flaw allowed an unauthenticated remote attacker to send specially crafted serialized data to a vulnerable Entra ID endpoint. Without adequate validation of the incoming data, the service reconstructed the malicious object, enabling the attacker to execute arbitrary code in the context of the affected service. No authentication was required. No user interaction was required. The CVSS score is 10.0, the maximum possible. Microsoft's advisory states the vulnerability has been fully mitigated and that there is no action for customers to take regarding patching. Microsoft has not disclosed when exploitation began, how long it was active, who was behind it, how many tenants were affected, or what the attacker did with code execution on Entra's backend. Microsoft has also not disclosed whether the code execution could be used to access tenant data, manipulate authentication tokens, alter access policies, or perform any specific action against connected Microsoft 365 or Azure environments. The disclosure exists under Microsoft's cloud service CVE transparency policy, which surfaces exploited flaws even when the fix is infrastructure-side, so customers can investigate whether they were affected.
Why it matters
Entra ID is not an endpoint. It is the identity control plane for the entire Microsoft cloud ecosystem. An attacker with code execution on Entra's backend is operating in the system that issues, validates, and revokes the authentication tokens that control access to every Microsoft 365 mailbox, SharePoint site, Teams channel, Azure resource, and third-party application integrated through the platform. Microsoft has confirmed exploitation occurred. Microsoft has not confirmed what the attacker did with that code execution access. The absence of information about scope, timing, and actor is not evidence of limited impact. It is the current limit of what Microsoft has chosen to disclose. For security teams at organizations that use Entra ID, the investigative question is whether there is any signal in their tenant's sign-in logs, conditional access logs, or token issuance logs from before the fix was deployed that is consistent with unauthorized access or token manipulation. Microsoft's disclosure was transparently motivated: the fix is in, but the breach investigation for any tenant that was affected during the exploitation window is still open.
Don't miss
Microsoft's cloud CVE transparency policy is worth understanding in its own right. When Microsoft discloses a CVE for a cloud service that has already been patched server-side, the advisory is specifically for customer awareness and investigation, not for remediation. The practical implication is that the typical workflow of receiving a CVE, identifying affected systems, and deploying a patch does not apply. The work for this disclosure is in the investigation: reviewing Entra sign-in and audit logs for anomalous token issuance, access policy changes, or service principal activity during the window before the fix; checking whether any enterprise application or service principal permissions changed unexpectedly; and reviewing conditional access policy changes in the Entra audit log. Microsoft Entra logs are accessible through the Entra admin center and through Microsoft Sentinel or any SIEM connected to Entra's diagnostic settings. The specific log query to run is against Entra's AuditLogs and SignInLogs tables for changes to service principals, application registrations, and conditional access policies during the period before today's disclosure.
Potential actions
- Review Entra ID audit logs for unexpected changes to service principals, application registrations, OAuth permissions, and conditional access policies. Focus the review on the period before today's disclosure, as the exploitation predated the fix. Access these logs through the Entra admin center under Monitoring and Health, Audit Logs, or through a connected SIEM using the AuditLogs table in Microsoft Sentinel.
- Review Entra sign-in logs for anomalous authentication patterns: sign-ins from unexpected locations or IP addresses, successful sign-ins for accounts that should not have been active, or sign-ins with unusual token scopes or claims. Token manipulation is a plausible exploitation outcome for code execution on the Entra backend, and sign-in logs would surface token-based access even if the manipulation itself leaves no Entra-side record.
- Ensure Entra diagnostic settings are configured to export sign-in and audit logs to a Log Analytics workspace or SIEM with adequate retention. If logs are not currently being exported with sufficient retention, the investigative window for this incident may already be closed. Configuring log export going forward ensures future incidents can be investigated with appropriate history.
The Sip
The patch is in. Microsoft applied it before telling anyone. The exploitation already happened. What Microsoft has not disclosed is what the attacker did, how long they had access, or how many tenants were affected. Review the Entra audit and sign-in logs for the period before today. The investigation window is open now and may not stay that way.