Microsoft has patched a critical vulnerability in Azure Automation that allowed attackers to potentially jump between cloud tenants, breaking the isolation that keeps one organization’s infrastructure separate from another’s. Tracked as CVE-2025-29827, the flaw scored 9.9 out of 10 on the CVSS scale – a rating that reflects remote attack feasibility, low required privileges, no user interaction, and high impact to confidentiality and integrity. The fix, implemented entirely on Microsoft’s side because Azure Automation is an exclusively hosted service, also changes a risky default setting that exposed automation accounts to the public internet.

The Vulnerability at a Glance

The core issue was improper authorization in Azure Automation. An attacker with a foothold in an Azure Automation account – meaning they already had some level of legitimate access to that account, even a low-privilege one – could exploit the flaw to elevate their privileges. In the worst-case scenario demonstrated by researchers, this could be chained with a default public endpoint to impersonate another organization’s Azure Automation managed identity. From there, the attacker could potentially execute runbooks, access secrets, and manipulate cloud resources as if they were a trusted administrator inside that victim tenant.

The CVSS vector makes the danger explicit: low privileges required (PR:L), no user interaction (UI:N), and a changed scope (S:C), meaning the compromise extends beyond the vulnerable component’s original authorization boundaries. Microsoft assigned a base score of 9.9, underscoring the severity. The flaw was categorized as an Elevation of Privilege vulnerability, rooted in CWE-285 (Improper Authorization) and also mapped to CWE-863 (Incorrect Authorization).

Why Every Azure Admin Should Care

Azure Automation isn’t just a scripting toy. It’s the engine behind countless critical workflows: deploying virtual machines, rotating secrets, patching servers, enforcing configuration, and orchestrating complex hybrid-cloud job schedules. Runbooks inside an Automation account typically execute under a managed identity – a non-human, machine-level identity that carries Azure RBAC roles. Those roles can be incredibly powerful, such as Contributor access to entire subscriptions, read/write permissions on Key Vault, or even privileged Microsoft Entra directory roles.

When a managed identity is over-permissioned, an attacker who hijacks it doesn’t need to steal a password or bypass MFA. They inherit the identity’s existing privileges immediately. That’s why CVE-2025-29827 is far more concerning than a standard “patch this bug” bulletin. It highlights a systemic risk: automation accounts often operate with far more power than they need, and cloud tenants are not always isolated as tightly as we assume.

Here’s the practical impact broken down:

  • For enterprise Azure admins: You must treat Automation accounts as high-security assets. A compromised automation identity could silently deploy malicious infrastructure, exfiltrate data from storage accounts, or tamper with backup routines. Even if Microsoft fixed the cross-tenant attack path, an attacker who already has internal access could abuse an overly broad managed identity to escalate privileges within your own tenant.
  • For IT pros managing hybrid environments: Hybrid Runbook Workers, which run on-premises servers or VMs, add another layer of risk. If a worker is over-permissioned or runs on a sensitive host (like a domain controller), the blast radius expands into Active Directory and on-premises systems.
  • For developers and DevOps teams: Webhooks that trigger runbooks are external entry points. If a webhook lacks strong authentication or runs a runbook with high privileges, it’s an invitation for abuse. Even without CVE-2025-29827, a poorly secured webhook could allow injection of malicious inputs.
  • For home users and small businesses: Azure Automation is an enterprise service; typical home users are unaffected. However, if you manage Azure resources via a Visual Studio subscription or a small lab, the same principles apply: review your automation permissions.

The Default Public Setting That Opened the Door

What made CVE-2025-29827 especially dangerous was a configuration default: Azure Automation’s identity endpoint was publicly reachable by default at the time the research was conducted. According to Dark Reading, security researcher Shay Shavit found that this public exposure, combined with the authorization flaw, could allow an attacker with access to one automation account to pivot into another tenant’s automation identity.

Public endpoints aren’t inherently insecure – many cloud services need them for webhooks, hybrid workers, and integrations. But when an endpoint handles identity-related operations (like retrieving tokens for managed identities), public accessibility turns a logical authorization bug into a practical, cross-tenant exploit. Microsoft’s response included not just fixing the authorization logic but also changing the default: Azure Automation identities are no longer public by default. New accounts are now private, forcing administrators to deliberately enable public access only when necessary.

This dual fix – code correction plus secure defaults – is textbook cloud security remediation. It shows that the vulnerability was not a simple one-off coding mistake but a design choice that amplified the risk.

How We Got Here: The Rise of Automation—and Its Shadow

Over the past decade, organizations have shifted from manually clicking through portals to automating everything in code. Tools like Azure Automation, PowerShell runbooks, and Azure Functions enabled reliable, repeatable operations at scale. Along the way, managed identities replaced static credentials, eliminating the tedium of secret rotation. But this progress also created a new class of privileged actors: non-human identities that operate at machine speed, often without human review.

The 2023 Midnight Blizzard attack on Microsoft’s corporate systems, where a legacy OAuth application with broad permissions was abused, demonstrated how devastating overly permissive service principals can be. Similar risks apply to Azure Automation managed identities. CVE-2025-29827 is a reminder that automation services are as trust-critical as domain controllers or IAM systems – perhaps more so, because they’re often forgotten once they “just work.”

Microsoft’s own security guidance has long warned about limiting managed identity permissions and avoiding subscription-scoped roles. But that guidance is frequently ignored in the rush to “get it working.” The result: thousands of Automation accounts with Owner or Contributor rights, many left public and unmonitored.

What You Need to Do Now: A Practical Audit Checklist

Microsoft’s platform fix protects the cross-tenant attack path, but it does not reduce the permissions your existing automation accounts hold – nor does it magically lock down accounts that were already public. You must act. Here’s a focused, task-oriented checklist.

1. Inventory Every Automation Account You Own

Run the following Azure CLI command to list all Automation accounts across your subscriptions:

az automation account list --query "[].{Name:name, ResourceGroup:resourceGroup, Location:location}"

Don’t just check production; include dev, test, sandbox, and legacy subscriptions. Note down any accounts you didn’t know existed.

2. Document the Managed Identity and Its Roles

For each account, identify its system-assigned or user-assigned managed identity and the roles granted to it. Use Azure Portal’s “Access control (IAM)” blade or the CLI:

az role assignment list --assignee <managed-identity-object-id> --all

Pay special attention to:
- Subscription-scoped Owner or Contributor roles
- Roles with wildcard actions (e.g., Microsoft.Compute/virtualMachines/*)
- Azure Key Vault access policies or RBAC roles that allow secret retrieval
- Microsoft Entra directory roles assigned to the managed identity (rare but possible)

3. Enforce Least Privilege Immediately

Create a dedicated custom role for each automation task that contains only the exact actions required. For example, a runbook that only needs to start/stop VMs should have a role with only Microsoft.Compute/virtualMachines/start/action and .../deallocate/action, scoped to the specific VM or resource group. Remove any broad built-in roles.

4. Disable Public Network Access Where Possible

Since the default is now private for new accounts, you should retroactively lock down existing ones. In the Azure Portal, go to the Automation account → Networking → Public access and set it to Disable. For accounts that truly require public connectivity (e.g., to receive webhook calls from external services), consider using Azure Private Link to bring traffic over the Microsoft backbone, or lock down webhook calls to specific IP ranges through request filtering.

Note: Microsoft documents that certain scenarios (like cloud jobs accessing Azure Key Vault or Azure SQL through private endpoints) are not currently supported. In those cases, evaluate whether the runbook can be migrated to a Hybrid Runbook Worker that sits within the virtual network. Do not blindly enable public access; instead, isolate the risky workflow.

5. Audit and Harden Webhooks

Webhooks enable HTTP-triggered runbooks, but each webhook URL contains a secret token. List all webhooks in an account:

az automation webhook list --automation-account-name <name> -g <group>

For each one:
- Verify it is still needed.
- Ensure the runbook it triggers does not accept unchecked parameters that might be used for resource manipulation.
- Consider rotating the webhook token if it has been exposed.
- If possible, replace webhooks with Azure Event Grid or Logic Apps that use managed identities for authentication.

6. Secure Hybrid Runbook Workers

Hybrid Runbook Workers extend automation to on-premises and VM-based hosts. Microsoft explicitly warns against placing the Hybrid Worker extension on domain controllers or other high-priority systems. Check your worker groups:

az automation hybrid-runbook-worker-group list --automation-account-name <name> -g <group>

Ensure each worker runs on a dedicated, hardened machine with limited local administrator access. Apply OS security baselines and keep the agent updated. Remove any workers that are no longer in use.

7. Enable and Monitor Activity Logs

Turn on diagnostic settings for each Automation account to stream logs to Log Analytics, Azure Monitor, or a SIEM. Focus on these events:
- Runbook job creation, publication, or deletion
- Changes to any webhook, variable, connection, or credential asset
- Role assignments to automation managed identities
- Unusual runbook execution patterns (e.g., a runbook that never runs suddenly executes 50 times)
- Cross-tenant access attempts (if you have Azure AD sign-in logs or Entra ID Protection)

Set up alerts for high-severity events. There’s no known in-the-wild exploitation of CVE-2025-29827 yet, but that’s no reason to skip post-remediation threat hunting.

Outlook: Automation Is Infrastructure, Manage It Like One

Microsoft handled the technical response well – patching the code and tightening defaults. But this vulnerability exposes a deeper issue: the industry still treats automation accounts as “tools” rather than as privileged infrastructure. A compromised managed identity can be more dangerous than a compromised admin account, because automation actions are harder to audit and less likely to raise immediate suspicion.

The fix for CVE-2025-29827 is free and automatic, but your security posture is yours alone. Use this moment as a forcing function to shrink every automation account’s permissions down to precisely what it needs, wall off public access unless absolutely necessary, and build detection that alerts you when a non-human identity starts behaving like an intruder. The next vulnerability might not be cross-tenant, but a runaway runbook with excessive rights can still destroy your environment from the inside.