Loading vulnerability…
Azure Automation Elevation of Privilege Vulnerability
A critical improper authorization vulnerability in Microsoft Azure Automation could allow an authenticated attacker to cross tenant trust boundaries and assume another tenant’s automation identity. The issue affected Azure Automation in a multi-tenant context and was described as an exploit chain involving three flaws: a public-by-default exposure of Azure Automation account endpoints combined with two additional code-level bugs. An attacker with access to their own Azure Automation account could leverage these conditions to impersonate a victim tenant’s automation identity and operate within the victim’s automation context.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation could enable cross-tenant identity takeover in Azure Automation. An attacker could create or modify automation runbooks, access sensitive configuration data or credentials stored in Azure Automation, and create, change, or delete cloud resources reachable through the compromised automation identity. Because Azure Automation accounts often hold privileged managed identities used for deployment, patching, secrets rotation, and operational workflows, the resulting impact could extend to broad privilege escalation across an organization’s Azure environment.
If you can’t patch tonight, do this now.
Restrict external exposure of Azure Automation endpoints unless there is a specific operational requirement. Review and minimize the scope of managed identities and tokens assigned to automation accounts, especially those used for high-privilege runbooks. Monitor Azure Automation activity for unexpected cross-tenant or anomalous runbook changes, credential access, and resource modifications. Apply least-privilege design to automation identities and segregate sensitive automation workflows where feasible.
Patch, then assume compromise.
Microsoft addressed the vulnerability in production. The documented service-side remediation included changing the default behavior so Azure Automation identities are no longer public by default. Organizations should ensure Azure Automation uses the remediated service configuration and review Microsoft’s advisory for any tenant-side follow-up actions. Security teams should also audit Azure Automation accounts and associated managed identities for excessive privileges and reduce permissions where possible.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
14 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.