If your organization uses Microsoft 365, Azure, or signs employees into anything with a Microsoft work account, Entra ID is quietly doing the work behind the scenes. It is the service that checks a password, approves a multi-factor prompt, and decides whether a login is trustworthy enough to hand over access to email, files, and applications. It is, in effect, the front door and the security guard for a huge share of corporate technology.
On August 20, 2026, Microsoft disclosed that a flaw in that front door, tracked as CVE-2026-69836 and rated the maximum possible severity score of 10.0 out of 10, had already been used by attackers before the company caught and fixed it. The unusual part of this story is not the severity score; critical flaws in identity systems happen. What is unusual is that there is no patch for your organization to install. Microsoft fixed this one entirely on its own servers, and the disclosure exists purely so customers know it happened. That is worth understanding in plain terms, because it changes what "responding" to this vulnerability actually looks like.
What is CVE-2026-69836?
CVE-2026-69836 is a remote code execution vulnerability in Microsoft Entra ID, the cloud-based identity and access management platform formerly known as Azure Active Directory. Entra ID handles authentication, single sign-on, and access policy enforcement for Microsoft 365, Azure, Dynamics 365, and a very large number of third-party applications that plug into it.
Microsoft's advisory describes the root cause plainly: "Deserialization of untrusted data in Microsoft Entra ID allows an unauthorized attacker to execute code over a network." The flaw is tracked under CWE-502, Deserialization of Untrusted Data, and carries a CVSS v3.1 score of 10.0, with a vector string indicating the attack requires no privileges, no user interaction, and low complexity to carry out over the network.
The vulnerability was discovered and reported by Robert Fitzpatrick, a Microsoft Principal Security Engineer. Microsoft has not published a technical write-up of how the flaw works internally, how it was found, or what a working exploit looks like, which is consistent with how the company generally handles vulnerabilities in services it fully controls rather than software that customers install and maintain themselves.
What does "deserialization of untrusted data" actually mean?
Deserialization is a normal, everyday process in software. When an application needs to send structured data, such as a user session or a set of settings, across a network or store it for later use, it often converts that data into a compact format for transmission. This is called serialization. The receiving system then reverses the process, called deserialization, turning that data back into a usable object inside the application.
The danger arises when an application deserializes data it received from somewhere it does not fully trust, without verifying that the data is actually what it claims to be. A malicious party can construct data that, when deserialized, does not just represent an object but actually causes the application to execute commands or code chosen by the attacker. This class of flaw has been behind some of the most severe vulnerabilities across enterprise software over the past decade, precisely because it can turn "the server processed a request" into "the server ran the attacker's code," without requiring a password or any prior access.
In Entra ID's case, this means an attacker who could reach the vulnerable component over the network, without logging in first, without tricking a user into clicking anything, could get the service to execute code on Microsoft's backend. That is about as severe as an identity platform vulnerability gets.
The disclosure model: why there is no patch for you to install
This is the detail that separates CVE-2026-69836 from most vulnerabilities we cover. Entra ID is what Microsoft classifies as an "exclusively hosted service." Microsoft owns, runs, and maintains every instance of it; there is no customer-managed server, no version number to check, and no update package to download.
Microsoft's advisory states this directly: "This vulnerability has already been fully mitigated by Microsoft. There is no action for users of this service to take. The purpose of this CVE is to provide further transparency."
That last sentence matters. Microsoft did not have to publish a CVE for a fully internal, already-fixed cloud vulnerability at all; historically, many cloud service providers have quietly patched backend issues without ever assigning a public identifier. Microsoft has been shifting toward disclosing these cloud-service flaws anyway, under an initiative it has described as "Toward Greater Transparency," specifically so customers have visibility into incidents that touched their environment even when there is nothing for them to configure or install.
The trade-off is that this transparency is thin. Microsoft has not disclosed who was behind the exploitation, when it began, whether it is still ongoing, how many organizations were affected, how the attack was technically carried out, or what attackers did once they had code execution inside the service. BleepingComputer reported that, as of its writing, no exploit code for CVE-2026-69836 was publicly available. That is a small mercy: it means the disclosure has not (yet) armed a wider pool of opportunistic attackers, even though the original attacker or attackers clearly had a working method before Microsoft intervened.
Active exploitation: what we know, and what we genuinely do not
Here is the honest state of public knowledge as of this writing:
What we know: Microsoft has explicitly marked CVE-2026-69836 as exploited in the wild. That designation was not applied lightly; Microsoft's Security Response Center reserves it for vulnerabilities where the company has direct evidence of real attack activity, not just theoretical risk. The vulnerability was not disclosed publicly before Microsoft's advisory, and there is no indication that an independent researcher found and leaked it under pressure, the way several vulnerabilities in our recent coverage have played out. That points toward Microsoft's own security engineering or incident response functions catching the activity themselves.
What we do not know: essentially everything about scope and attribution. There is no confirmed attacker group, no confirmed start date for exploitation, no confirmed end date, no confirmed list or count of affected tenants, and no confirmed description of post-exploitation activity. Multiple outlets covering this story, including Help Net Security, noted plainly that Microsoft has not disclosed any of these details.
For a service that underpins sign-in and access control for millions of organizations globally, that is a wide zone of uncertainty. It is reasonable to want more, and reasonable for Microsoft not to have provided it yet; identity platform incidents are exactly the kind of thing where premature detail can help attackers more than it helps defenders.
Why an identity platform flaw deserves extra attention, even a patched one
A vulnerability in a typical application server puts that application at risk. A vulnerability in the identity layer is different in kind, not just degree, because identity is the thing every other system relies on to decide who is allowed in.
Successful exploitation of a deserialization flaw in Entra ID, in the worst case, could have given an attacker code execution inside the very service responsible for issuing authentication tokens, evaluating conditional access policies, and enforcing multi-factor requirements across an organization's Microsoft ecosystem. Depending on what an attacker did with that access before the fix was deployed, the theoretical downstream effects range from reading sensitive configuration data, to manipulating access policies, to forging or abusing authentication tokens that could grant access to connected cloud workloads, email, and applications.
To be clear: Microsoft has not confirmed that any of these specific outcomes occurred. The point is not to speculate about what did happen, but to explain why "it's already patched" is not, on its own, a complete answer for an identity system that sits at the center of your access model.
This is not Entra ID's first maximum-severity moment this year
CVE-2026-69836 is notable on its own, but it also arrives less than a year after another critical Entra ID vulnerability made headlines. In September 2025, Microsoft patched CVE-2025-55241, a privilege escalation flaw reported by independent researcher Dirk-jan Mollema of Outsider Security, that could have allowed an attacker to gain complete administrative access to any organization's Entra ID tenant, worldwide, given the right conditions.
Two maximum or near-maximum severity Entra ID vulnerabilities within a year is not, by itself, proof of a systemic problem; large, complex cloud identity platforms are difficult to secure perfectly, and finding these issues (whether by Microsoft internally or by outside researchers) is a sign the system is being scrutinized closely. But for organizations that treat Entra ID as a "set it and forget it" piece of infrastructure because it is cloud-managed, this is a reasonable prompt to revisit that assumption, at least with respect to monitoring and logging discipline, even when there is no patch to apply.
The wider patch batch this flaw arrived in
CVE-2026-69836 was disclosed alongside a substantial round of Microsoft security updates on August 20, 2026, totaling 22 patches across Azure, Entra ID, Exchange, Fabric, and Partner Center. Several of the other flaws in the same batch also carried the maximum CVSS score of 10.0:
| CVE | Product | Type |
|---|---|---|
| CVE-2026-69836 | Entra ID | Remote code execution (exploited) |
| CVE-2026-65816 | Azure Arc | Elevation of privilege (unauthenticated, remote) |
| CVE-2026-69555 | Azure Arc | Elevation of privilege (unauthenticated, remote) |
| CVE-2026-65801 | Exchange Online | Elevation of privilege (unauthenticated, remote) |
| CVE-2026-65770 | Azure Managed Instance for Apache Cassandra | Remote code execution |
A further seven critical elevation-of-privilege issues were resolved across Azure SQL Database, Microsoft Fabric, Azure Logic Apps, Azure Data Factory, and Entra ID itself (CVE-2026-69851), alongside a number of high-severity fixes in Azure Virtual Machines, Partner Center, Azure Stack HCI, and Copilot in Azure. As with CVE-2026-69836, the large majority of these were cloud-service flaws requiring no customer action, since Microsoft deployed the fixes server-side.
The scale of this release, and the fact that four separate flaws in the batch hit the maximum severity ceiling, reflects a broader pattern this month: Microsoft has also been dealing with a Windows Defender zero-day dubbed ShieldBreak (CVE-2026-69414), an actively exploited Windows IKE Extension flaw flagged by CISA, and, earlier in August, a Windows zero-day exploited by the North Korea-linked Lazarus Group as part of its long-running Operation Dream Job campaign. None of those are directly related to CVE-2026-69836, but they paint a picture of a demanding month for Microsoft's security response teams.
What should you do?
Because Microsoft has already deployed the fix and there is no update to install, this section looks different from our usual patch-and-mitigate guidance. The right response here is about visibility, not remediation.
1. Understand there is genuinely nothing to patch
Confirm internally, especially with any leadership or audit stakeholders who may ask, that CVE-2026-69836 does not require a configuration change, a software update, or a service restart on your end. Microsoft has resolved it entirely within its own infrastructure. Framing this correctly matters, since teams sometimes burn hours searching for a patch that does not exist for this category of cloud-service CVE.
2. Review sign-in and audit logs for the exploitation window
Since exploitation occurred before public disclosure, and Microsoft has not specified a start date, a prudent posture is to review your Entra ID sign-in logs, audit logs, and risk detections covering at least the past several weeks for anomalies. Specifically look for:
- Unusual or unexplained sign-ins, particularly from unfamiliar locations, IP ranges, or applications
- Unexpected changes to conditional access policies
- New or modified app registrations and service principals you do not recognize
- Newly granted admin role assignments, particularly Global Administrator or other privileged roles
- Anomalous token issuance patterns, including tokens with unusual lifetimes or scopes
3. Reassess privileged role assignments
Given that this flaw touched the identity layer itself, it is worth taking the opportunity to review who currently holds privileged Entra ID roles and whether that access is still justified. This is good hygiene regardless of this specific CVE, but it is a natural moment to do it.
4. Verify conditional access and MFA enforcement remain intact
Confirm that your conditional access policies and multi-factor authentication requirements are configured and enforcing as expected, with no unexpected exclusions or gaps. This will not undo any exploitation that already happened, but it reduces the value of any credentials or tokens an attacker may have obtained during the exposure window.
5. Watch for further Microsoft disclosure
Microsoft has left significant gaps in its public account of this incident. If the company releases further detail, such as indicators of compromise, an affected-tenant notification process, or a technical root-cause write-up, treat it as a trigger to revisit your log review with that new information in hand.
A note on this disclosure model going forward
We expect to see more vulnerabilities like this one: severe, exploited, and fully resolved before the public ever learns their name. It is a reasonable model for cloud providers to follow, since it avoids the scenario where publishing details before a fix is ready simply hands attackers a roadmap. But it does put customers in an uncomfortable position: trusting that "fully mitigated, no action required" also means "nothing further to worry about," without the ability to independently verify that for their own environment.
Our recommendation is not to treat these disclosures passively. A "no action required" cloud CVE is still useful information: it tells you a window existed where a component central to your environment was vulnerable, and it is reasonable to spend an hour or more confirming your own logs look clean across that window, even when Microsoft has not told you exactly when it opened or closed.
Summary
| CVE | CVE-2026-69836 |
| CVSS Score | 10.0 (Critical) |
| Type | Remote Code Execution via Deserialization of Untrusted Data (CWE-502) |
| Component | Microsoft Entra ID (formerly Azure Active Directory) |
| Attack vector | Network, unauthenticated, no user interaction, low complexity |
| Discovered by | Robert Fitzpatrick, Microsoft Principal Security Engineer |
| Disclosed | August 20, 2026 |
| Actively exploited? | Yes, confirmed by Microsoft; scope and timeline not disclosed |
| Public exploit code? | Not publicly available as of writing |
| Patch required from customers? | No; fully mitigated server-side by Microsoft |
| Recommended action | Review Entra ID sign-in and audit logs, privileged role assignments, and conditional access policies for anomalies |
| Related context | Disclosed alongside 22 total Microsoft patches, including four other maximum-severity (10.0) flaws in Azure Arc, Exchange Online, and Azure Managed Instance for Apache Cassandra |
If you need help reviewing your Entra ID sign-in logs and privileged access assignments for signs of anomalous activity, or want a second set of eyes on your conditional access configuration, get in touch. A vulnerability you cannot patch is still one worth investigating, and that is exactly the kind of review CrowdSOC is built to help with.