A Single Default Setting in Azure Automation Could Have Let Hackers Steal Any Tenant's Cloud Identity
A researcher found that Microsoft's cloud automation service was, by default, leaving account identities visible to the public internet, giving any attacker a path to impersonate other organisations' privileged accounts.
Key points
- Microsoft patched CVE-2025-29827, rated 9.9 out of 10 for severity, in its Azure Automation service after researcher Shay Shavit reported the flaw.
- The vulnerability let any attacker with their own Azure account impersonate a completely different organisation's automation identity inside Microsoft's cloud.
- The exploit chained three flaws: a default configuration that made account endpoints publicly reachable, plus two code-level bugs.
- Microsoft changed the default setting and says no real-world attacks exploited the vulnerability before the fix.
- Organisations should audit the permissions tied to their cloud automation accounts and avoid exposing any endpoint that does not need to be public.
Microsoft quietly fixed a serious flaw that could have let criminals walk into any organisation's cloud environment dressed as a trusted insider. The vulnerability sat inside Azure Automation, a Microsoft cloud service companies use to run scheduled scripts for IT tasks: patching servers, rotating passwords, deploying software. Those scripts run under a managed identity, essentially a set of keys that says "this script has permission to touch these systems."
What actually went wrong?
By default, those identity endpoints were public. Anyone on the internet could reach them.
Shay Shavit, a senior security researcher on Microsoft's Azure Networking Security Research team, spotted that the default setting made Azure Automation account endpoints visible to anyone, not just the organisation that owned them. Two additional code-level bugs, when combined with that open door, let him cross what is called a "trust boundary": the line that is supposed to stop one organisation's cloud account from touching another's.
With the boundary crossed, an attacker holding their own legitimate Azure account could assume the identity of a completely different company's automation account, then create or delete cloud resources, read stored credentials, or rewrite the automation scripts themselves. Shavit put it to Dark Reading plainly: "If you have a strong enough identity, you're the king."
The flaw was assigned the identifier CVE-2025-29827 and a severity score of 9.9 out of 10. The Microsoft Security Response Center issued an advisory after Shavit reported it internally.
| Detail | Value |
|---|---|
| CVE identifier | CVE-2025-29827 |
| Severity score (CVSS) | 9.9 / 10 |
| Affected service | Azure Automation |
| Flaw count in exploit chain | 3 (1 config default, 2 code bugs) |
| Known real-world attacks | None confirmed |
| Default setting now | Private (changed by Microsoft) |
Should Azure customers be worried?
Microsoft says no attacks happened before the fix, and the default setting is no longer public. The immediate risk has been removed.
Shavit's advice is still worth acting on. He recommends auditing the scopes, the permission boundaries attached to any cloud automation account, and removing access that is broader than strictly necessary. Think of it like checking that a spare key left under the doormat has now been taken inside: the crisis is over, but a tidy-up makes sense. This pattern of over-broad cloud identity permissions is one we have been tracking closely; our 22 July piece on AI assistants handed admin rights shows how quickly a compromised identity can become a company-wide incident.
Chain-thinking is the real lesson here. A low-severity bug on its own rarely looks dangerous. Joined with two others, it can become a master key.
Common questions
Does this affect ordinary Microsoft users?
No. Azure Automation is an enterprise IT tool, not a consumer product. Personal accounts and everyday business apps like Word or Teams were not involved.
Did adding multi-factor authentication (MFA, a second login check such as a text message code) protect against this?
Not here. The attack exploited how the service was configured, not a stolen password, so an extra login step would not have blocked it. Changing the default setting and patching the code flaws was the actual fix.
