Microsoft Entra ID RCE CVE-2026-69836 (CVSS 10.0) Was Exploited in the Wild
Microsoft says a maximum-severity remote code execution flaw in Entra ID, CVE-2026-69836, was exploited in the wild before it fixed the service on its own infrastructure. No patch to install does not mean there is nothing for security teams to check.
Microsoft has confirmed that CVE-2026-69836, a remote code execution flaw in Microsoft Entra ID rated a maximum CVSS 10.0, was actively exploited in the wild before the company fixed it on its own servers. Entra ID is the cloud identity and access management service that used to be called Azure Active Directory, and it sits underneath sign-in for millions of Microsoft 365 and Azure tenants. A control-plane bug of this severity is about as close to a worst case as identity gets: the layer that decides who you are was, for some window of time, remotely exploitable by an unauthenticated attacker.
The reassuring half of Microsoft's message is real. Because Entra ID is a fully managed service, Microsoft says it has already mitigated the flaw and that there is "no customer action required." There is no update to download, no KB to chase, no config toggle to flip. The uncomfortable half is the part the advisory does not spell out: a server-side fix closes the door going forward, but it tells you nothing about whether your tenant was walked through that door while it was open. That gap is where defenders still have work to do.
What Microsoft Actually Disclosed
Microsoft published the advisory on Thursday, August 21, 2026, and kept it short. The company classed the bug as a deserialization issue: "Deserialization of untrusted data in Microsoft Entra ID allows an unauthorized attacker to execute code over a network," it wrote in the Microsoft Security Response Center advisory for CVE-2026-69836. That maps to a well-understood weakness class (CWE-502), where a system rebuilds attacker-controlled data into live objects without validating it first. The maximum score follows from the combination the vector describes: reachable over a network, no authentication, no user interaction, and code execution as the outcome.
On the exploitation and remediation status, Microsoft was equally direct. "This vulnerability has already been fully mitigated by Microsoft," the advisory reads. "There is no action for users of this service to take." Microsoft credited one of its own principal security engineers with finding and reporting the flaw, which suggests it was caught internally rather than by an outside researcher or a breach disclosure. As The Hacker News reported, the advisory does not say how the flaw was exploited, when that activity started, whether it is still ongoing, or how it was discovered.
Withholding those specifics is defensible while exploitation risk is live, and reproducing them would not help defenders anyway. But it does leave every Entra ID customer with the same unanswerable question at the same time: was my tenant one of the ones touched? Microsoft has not published a list of affected tenants, and nothing in the advisory lets an individual customer rule themselves in or out.
Why a Control-Plane RCE in Entra ID Is Different
A remote code execution flaw in an ordinary application compromises that application. The same flaw in the identity control plane sits under everything that trusts it. Entra ID issues the tokens that Microsoft 365, Azure, and thousands of third-party apps accept as proof of who a user is, so when the layer that mints and validates those tokens is the thing under attack, the blast radius is not one server but the trust fabric itself. That is why an unauthenticated, network-reachable RCE here earns a flat 10.0, and why the word maximum is doing real work rather than marketing.
The point is not to guess what any specific attacker did, because Microsoft has not said. The point is why defenders should care even after the fix: control-plane access is the kind of foothold that lets an intruder create durable identities and grants that outlive the original hole. A forged trust relationship, a rogue application with standing permissions, or an extra owner on a privileged role does not get cleaned up when Microsoft patches its own code. Those artifacts live in your tenant, and only you can find and remove them. A server-side fix stops new exploitation; it does not roll back whatever was already set up.
Why "No Customer Action Required" Is True and Incomplete
"No customer action required" is an accurate statement about patching. It is not a statement about your logs. Microsoft owns the vulnerable code and the infrastructure it ran on, so Microsoft is the only party that could apply the fix, and it has. There genuinely is no patch for you to install. What Microsoft cannot do from its side is tell you whether an attacker who reached the control plane during the exposure window used that access to touch your specific tenant, and if so, what they changed.
This is the same shape we have seen in other cloud control-plane incidents, where a provider quietly fixes a platform-wide flaw and customers are left to reconstruct their own exposure from telemetry. It is worth separating two ideas that the phrase "no action required" tends to collapse together: remediation (done, by Microsoft) and verification (not done, and only you can do it for your tenant). The diagram below draws that split.
● No Patch, Still Work CVE-2026-69836 splits cleanly into what Microsoft already handled and what only your team can confirm. |
Remediation → Done by Microsoft The flaw lived in Entra ID’s control plane. Microsoft fixed the service on its own infrastructure. There is no package, KB, or config change for customers to apply. |
↓ |
Verification → Still on You Microsoft cannot tell you whether your tenant was touched during the exposure window. Your sign-in logs, app and service-principal changes, conditional-access edits, and privileged role grants are the only record you control. |
Source: The CyberSignal analysis of the MSRC advisory for CVE-2026-69836 (2026-08-21). |
Remediation was Microsoft’s job and is finished. Verifying whether your own tenant was abused during the exposure window is not.
What Defenders Should Check Anyway
Even with no patch to apply, the right move is a targeted log review across the period before Microsoft's fix landed. You are not looking for the exploit itself, which happened inside Microsoft's infrastructure and is not visible to you. You are looking for the second-order signs that someone used control-plane access to establish persistence or escalate inside your tenant. Concretely, pull and review the following in the Entra ID audit and sign-in logs:
- Sign-in logs for anomalous successful authentications, especially for privileged accounts, from unfamiliar IPs, ASNs, or geographies, and any tokens issued outside your normal conditional-access constraints.
- Service-principal and app-registration changes: new app registrations, added client secrets or certificates, and new or broadened API permissions (particularly application-level Graph permissions). Rogue service principals are a favorite persistence mechanism because they survive user password resets.
- Conditional-access policy modifications: any policy that was disabled, deleted, or weakened, or new exclusions added, over the window.
- Privileged role assignments: additions to Global Administrator, Privileged Role Administrator, Application Administrator, and similar directory roles, including eligible assignments in Privileged Identity Management.
- Federation and domain settings: new or altered federated domains or trust configurations, which can enable token forgery that outlasts any single fix.
If your organization forwards Entra ID logs to a SIEM, extend the query window generously rather than guessing at the exact exposure period, since Microsoft has not published one. If you do not centralize these logs, note that Entra ID audit-log retention is limited by default (roughly 30 days on lower tiers), which is its own reason to act now rather than later. If you do spot something, pull the thread downstream: correlate suspicious Entra ID events with Microsoft 365 and Microsoft Graph sign-in activity, and be ready to revoke sessions, rotate secrets on any suspect app registration, and remove role holders you cannot account for. Preserve the logs you have today, because the evidence ages out on that default retention clock. None of this is exotic threat hunting. It is the identity hygiene review you would run after any suspected control-plane exposure, and it is the only part of this incident you can actually verify. For teams that have been tracking Microsoft's recent run of identity and cloud issues, this fits a pattern we covered when Varonis disclosed the CoSnitch flaws in Microsoft Copilot and when CISA flagged four actively exploited flaws including Microsoft components.
Identity Keeps Being the Target
This lands in a year when the identity layer, not the endpoint, has been where the serious cloud incidents keep surfacing. The specifics differ each time, but the through-line is consistent: attackers go after the systems that issue trust, because one success there is worth thousands of individual account compromises. That is the argument for treating your Entra ID configuration as a monitored, change-controlled asset rather than a set-and-forget dependency. Alert on new privileged role grants and new app credentials as a standing control, not a one-time sweep, so the next time a control-plane flaw shows up in a headline you are reading your own alerts instead of scrambling to build the query from scratch.
What We Still Do Not Know
Several load-bearing questions remain open, and it is worth being explicit about them rather than filling the gaps with assumptions:
- The exposure timeline is unconfirmed. Microsoft has not said when exploitation began, whether it predated the advisory, or when the fix was deployed relative to the attacks. Treat the window as unknown and review broadly.
- Attribution is unconfirmed. No threat actor has been named, and Microsoft has not characterized the activity as targeted or opportunistic.
- Victim scope is unconfirmed. No affected tenants have been publicly identified, and there is no public evidence that abuse reached across tenant boundaries. Do not assume your tenant was hit; also do not assume it was spared.
- Exploit specifics are withheld. The advisory names the weakness class (deserialization of untrusted data) but not the vulnerable endpoint or the technique. That is appropriate while risk is live, and it does not change the defender playbook above.
My read: the substance of Microsoft's response looks right, and an internally discovered, silently fixed control-plane bug is genuinely better handled than one disclosed after a public breach. But "no customer action required" is a remediation statement doing double duty as an all-clear, and it should not be read as the second thing. The honest version is: Microsoft has closed the hole, and you should still spend an hour in your Entra ID logs confirming nobody set up shop in your tenant while it was open. That is an assessment, not a Microsoft statement, and it costs little to be wrong about in the cautious direction.
