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 relied on three chained flaws, the most consequential being a default configuration that made account endpoints publicly reachable.
- 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 last year 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 that companies use to run scheduled scripts for everyday IT tasks: patching servers, rotating passwords, deploying software. Those scripts run under a special kind of account called a managed identity, which is 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 own 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. He then found two additional code-level bugs that, 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.
The result: an attacker with their own legitimate Azure account could assume the identity of a completely different company's automation account. With that identity, they could create or delete cloud resources, read stored credentials, or rewrite the automation scripts themselves. Shavit described it simply: "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. If your organisation uses Azure Automation, the immediate risk has been removed by the patch.
That said, Shavit's advice is worth taking seriously. He recommends that teams audit the permissions, called scopes, attached to any cloud automation account and remove 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 still makes sense.
This is also a good moment for IT teams to remind themselves of a basic principle: a low-severity bug on its own rarely looks dangerous. Chained with two others, it can become a master key.
Common questions
Does this affect ordinary Microsoft 365 users?
No. Azure Automation is an enterprise IT tool, not a consumer product. Personal accounts, email, 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?
Honestly, not here. The attack used a misconfiguration in how the service was set up, not a stolen password, so an extra login step would not have blocked it. The real fix was changing the default setting and patching the code flaws.
