A critical vulnerability in Microsoft’s Azure Automation service could have exposed accounts to cross-tenant identity takeovers due to a default setting that had the potential to make account identities become public.
Azure Automation is widely used by Microsoft internally and by enterprises running Azure for DevOps, resource deployment, patching, and secrets rotation using scripted runbooks tied to embedded managed identities. Shay Shavit, a senior security researcher on Microsoft’s Azure Networking Security Research team, discovered the vulnerability last year and reported it to the Microsoft Security Response Center (MSRC), which issued an advisory.
Azure Automation Elevation of Privilege Vulnerability (CVE-2025-29827), which was assigned a CVSS score of 9.9, allows an attacker with access to their own Azure Automation account to breach the trust boundary and assume another tenant’s automation identity. This would enable them to create or modify automation scripts and access sensitive configuration data or credentials stored in Azure Automation accounts. A successful attacker could also create, change, or delete resources across an organization’s cloud workloads.
Shavit tells Dark Reading that there have been no known exploits of the vulnerability, but in his demonstration at next month’s Black Hat USA conference in Las Vegas, he plans to show how the default configuration poses a risk to Microsoft and its customers. The default setting for Azure Automation identities is no longer public, Shavit says.
“At the time, the default for an automation account was to be made public, at least for the endpoint, which we exploited,” he explains. “Hence, that’s why this was kind of messy, because when the default is public, then you can access a lot of accounts, potentially, of course.”
Shavit and his research team selected Azure Automation as a research target because its accounts typically hold privileged identities, and then worked to breach the trust boundary between the service and those identities, he says. Once an attacker breaches the identity, they can access other accounts.
“It’s the endgame because if you have a strong enough identity, you’re the king in the world,” he says. “You don’t really need to continue your exploitation; you can do whatever you want, either in the portal, in the [command-line interface, or] in the APIs. So that’s what we successfully achieved.”
Even though the default setting was changed, Shavit recommends that organizations avoid exposing anything external unless there’s a specific need to do so. Organizations can also lower their risk by auditing the scope of identities and tokens assigned to cloud automation accounts.
This vulnerability is an example of how subtle misconfigurations and logic flaws can be chained to enable high-impact attacks, Shavit says. The exploit chain consisted of three distinct flaws, he notes: the default configuration that made Azure Automation accounts publicly accessible, plus two separate code-level bugs.
Shavit’s finding is not the first vulnerability discovered in the Azure Automation service. In 2021, researchers at Orca Security discovered a flaw that could exfiltrate managed identity tokens from a shared sandbox server. At that time, Orca reported the vulnerability, dubbed AutoWarp, to Microsoft’s Security Response Center (MSRC). Microsoft publicly disclosed the issue in March 2022 and stated that it had not detected any evidence of token misuse.
Although the two vulnerabilities share the same goal — extracting a victim’s managed identity — the attack chains differ, Shavit says. AutoWarp exploited the service’s code-execution component to establish a reverse shell, whereas Shavit’s discovery doesn’t affect code execution. While Orca described AutoWarp as critical, it never received a CVE identifier and doesn’t appear in the National Vulnerability Database (NVD).
Nevertheless, Shavit believes the research underscores a broader shift in cloud risk.
“Identities in cloud environments have become a very focal point because they facilitate and enable an attacker to do so much when one is compromised,” he says.
For defenders, he suggests they avoid evaluating vulnerabilities in isolation and instead map the paths that connect them, rather than assuming a single low-severity bug poses little risk on its own.
“Think about the chain — think about the attack path,” Shavit says.
