Microsoft has remediated a critical Azure Automation privilege-escalation vulnerability that researchers showed could be chained with a risky default exposure model to breach a cloud provider’s most important security boundary: the boundary between separate Microsoft Entra tenants. Tracked as CVE-2025-29827, the flaw concerns improper authorization in Azure Automation and carried a Microsoft-assigned CVSS 3.1 score of 9.9 out of 10—a rating that reflects remote reachability, low required privileges, no user interaction, and the potential for cross-scope impact. Petri reports that Microsoft has fixed the authorization weakness and changed the default configuration that contributed to the risk.
Azure Automation is not merely another administrative utility in the Azure portal. It is a cloud automation platform used to execute runbooks—scripts and workflows that can deploy infrastructure, rotate secrets, manage virtual machines, apply updates, enforce configuration, and coordinate tasks across Azure and hybrid environments. Microsoft describes it as a service for orchestrating repetitive, operationally important, and mission-critical work across cloud and hybrid infrastructure. Microsoft Learn
That operational role makes Azure Automation accounts unusually sensitive. A runbook may act through a managed identity that has been granted access to Azure resources, Microsoft Entra-protected services, Key Vault, storage, virtual machines, or application environments. In a correctly designed implementation, the managed identity removes the need to embed long-lived credentials in scripts. But it also means that an automation account can become a high-value trust anchor. Microsoft Learn
CVE-2025-29827 was assigned to Azure Automation Elevation of Privilege Vulnerability. Its official description is concise: improper authorization in Azure Automation could allow an authorized attacker to elevate privileges over a network. The National Vulnerability Database lists Azure Automation as the affected product and identifies the underlying weakness as CWE-285, Improper Authorization, while NIST’s analysis additionally maps it to CWE-863, Incorrect Authorization. NVD
The important distinction is that this was not presented as a simple case of an anonymous internet attacker instantly taking control of an Azure subscription. The CVSS vector requires low privileges (
That is why the most concerning aspect of the Azure Automation flaw is not simply privilege escalation. It is the reported ability, under the right conditions, to cross an Azure tenant boundary and assume or misuse another organization’s automation identity. Petri reports that the vulnerability could be combined with a risky default configuration and other application weaknesses to impersonate another organization’s automation identity.
Reporting from Dark Reading adds important technical context. Researcher Shay Shavit, a senior security researcher on Microsoft’s Azure Networking Security Research team, found that an attacker with access to an Azure Automation account could potentially breach the expected trust boundary and assume another tenant’s automation identity. From there, the attacker could potentially create or modify automation scripts, access configuration data or credentials held by Automation accounts, and manipulate cloud resources reachable by the compromised identity.
This is exactly the kind of failure mode that security architects fear in automation services. Automation is designed to act at machine speed and often operates without interactive human approval. If an identity entrusted to a runbook is compromised, the attacker may not need to steal a password, defeat multifactor authentication, or persuade a user to authorize a malicious application. They may instead inherit the capabilities already delegated to the automation layer.
That difference matters operationally. Organizations can have strong encryption, multi-factor authentication, and modern endpoint protection while still being exposed if a cloud control plane incorrectly authorizes an operation or allows an identity assertion to cross a boundary it should never cross.
The official CVE record reflects that concern. Microsoft’s CVSS vector includes
Microsoft’s managed identity guidance illustrates the model directly: an Azure Automation account can obtain tokens for other Microsoft Entra ID-protected resources, and those tokens represent the Automation account rather than a human user. Microsoft also explicitly advises assigning only the permissions a runbook needs—for example, VM start/stop rights rather than broad control-plane permissions, or read-only access when the task only reads blob storage. Microsoft Learn
This is an essential benefit of managed identities. They can eliminate embedded credentials and reduce secret-management overhead. However, managed identities do not make authorization design optional. They shift the security question from “Where is the password?” to “What can this non-human identity do, where, and under what conditions?”
Microsoft’s Azure Automation security guidance recommends granular Azure RBAC roles, discourages broad role assignments at subscription scope, and advises against wildcard actions in custom roles. It also notes that runbook-level role-based access should be used when a user does not need access to every runbook in an Automation account. Microsoft Learn
Those recommendations are not generic compliance boilerplate in the context of CVE-2025-29827. They are direct mitigations for the real-world impact of authorization failures. A platform-level fix can prevent the specific cross-tenant exploit path, but narrowly scoped roles still determine what a compromised or abused automation identity could do within its own environment.
The distinction between publicly reachable and insecure is important. Many Azure services provide public endpoints for legitimate reasons, including webhooks, cloud management, hybrid worker communications, and integrations. Public reachability is not automatically a vulnerability.
But public reachability becomes dangerous when it interacts with an authorization defect. A service may correctly expose an endpoint to enable automation from distributed systems, but if that endpoint accepts or processes identity-related requests without enforcing appropriate tenant, resource, and caller boundaries, the endpoint can become a gateway to a much larger compromise.
Microsoft has reportedly addressed both sides of the problem: the authorization flaw itself and the default configuration that contributed to exposure. Petri says Microsoft changed the default configuration as part of the remediation, while Dark Reading reports that Azure Automation identities are no longer public by default.
A secure default does not eliminate the ability to expose a service where needed. Instead, it makes exposure an intentional administrative choice that must be justified by a business workflow. That approach reduces the number of reachable assets, makes risky designs more visible during review, and gives organizations a clearer inventory of services that genuinely require public access.
For Azure administrators, the practical takeaway is that a configuration review should not stop at “is the CVE fixed?” It should also ask:
The CVE record labels the issue as an exclusively-hosted-service vulnerability. That means enterprises should not expect a traditional operating-system patch for Azure Automation itself.
However, “Microsoft has fixed it” should not translate into “there is nothing for customers to do.” The platform remediation closes the identified defect, but customer-owned configuration remains customer-owned. Organizations still control the identities attached to Automation accounts, the RBAC roles they receive, the webhooks that invoke runbooks, the runbook content, network exposure, worker placement, and access-monitoring strategy.
This is a common cloud shared-responsibility reality. The provider must secure the service control plane and tenant-isolation mechanisms. The customer must reduce unnecessary privilege, eliminate stale accounts and runbooks, isolate sensitive workflows, and watch for signs that automation is being used in unexpected ways.
For each account, identify:
Security teams should pay particular attention to:
For applicable Automation workloads, administrators can configure an Automation account to deny public configurations and allow connections only through private endpoints by setting the
There are design tradeoffs. Microsoft documents that, in the current implementation, Automation cloud jobs cannot access certain Azure resources secured through private endpoints, including Azure Key Vault, Azure SQL, and Azure Storage; it points to Hybrid Runbook Workers as the workaround for those scenarios. Microsoft Learn This limitation means private networking should be planned as an architecture decision, not applied blindly in production.
Security teams should determine whether each webhook remains necessary and whether it can be replaced with a more strongly authenticated workflow. They should also ensure that runbooks triggered through webhooks do not accept uncontrolled inputs that can alter resource targets, subscription contexts, scripts, or identity behavior.
Microsoft warns that a user with VM Contributor rights or permissions to run commands on an unrestricted Hybrid Worker machine could potentially obtain Automation credentials and gain access equivalent to a subscription contributor. It also strongly advises against placing the Hybrid Worker extension on a domain controller. Microsoft Learn
That guidance should be treated as a high-priority architectural rule:
Security operations teams should review historical activity for unexpected changes involving Automation accounts, managed identities, runbooks, and role assignments. The goal is not to search for one known exploit signature but to find anomalous actions that would be meaningful if an automation identity had been misused.
Priority review areas include:
The severity rating also deserves credit. A 9.9 critical score communicates that the potential impact was not a routine permission edge case. Microsoft’s CVSS assessment explicitly recognizes a low-privilege remote attack path with a changed scope and high confidentiality and integrity impact. NVD
Yet the incident also exposes an enduring cloud-security risk: organizations often invest heavily in preventing initial access while giving insufficient attention to the non-human identities that run their infrastructure. A compromised user account is visible and familiar. A compromised automation identity can be quieter, more persistent, and more dangerous because it is expected to execute scripts and make changes.
Azure Automation remains a powerful and legitimate platform for Windows administrators, cloud engineers, and enterprise operations teams. The correct response is not to abandon it. It is to operate it as privileged infrastructure: minimize identity permissions, restrict public access, isolate worker systems, secure webhook paths, review every trust relationship, and log enough context to detect when automation starts doing something that automation was never meant to do.
CVE-2025-29827 is therefore more than a single Azure Automation vulnerability. It is a reminder that in modern cloud environments, automation identities are administrators, and every administrative identity must be designed, constrained, monitored, and defended accordingly.
Overview: Why CVE-2025-29827 Matters
Azure Automation is not merely another administrative utility in the Azure portal. It is a cloud automation platform used to execute runbooks—scripts and workflows that can deploy infrastructure, rotate secrets, manage virtual machines, apply updates, enforce configuration, and coordinate tasks across Azure and hybrid environments. Microsoft describes it as a service for orchestrating repetitive, operationally important, and mission-critical work across cloud and hybrid infrastructure. Microsoft LearnThat operational role makes Azure Automation accounts unusually sensitive. A runbook may act through a managed identity that has been granted access to Azure resources, Microsoft Entra-protected services, Key Vault, storage, virtual machines, or application environments. In a correctly designed implementation, the managed identity removes the need to embed long-lived credentials in scripts. But it also means that an automation account can become a high-value trust anchor. Microsoft Learn
CVE-2025-29827 was assigned to Azure Automation Elevation of Privilege Vulnerability. Its official description is concise: improper authorization in Azure Automation could allow an authorized attacker to elevate privileges over a network. The National Vulnerability Database lists Azure Automation as the affected product and identifies the underlying weakness as CWE-285, Improper Authorization, while NIST’s analysis additionally maps it to CWE-863, Incorrect Authorization. NVD
The important distinction is that this was not presented as a simple case of an anonymous internet attacker instantly taking control of an Azure subscription. The CVSS vector requires low privileges (
PR:L), which means an attacker needed some legitimate starting point—such as access to an Azure Automation account or an environment where one could be created or controlled. Yet the potential outcome was far more serious than the initial foothold: escalation to a more privileged identity and, in the demonstrated chain, a possible move across tenant boundaries.The Cross-Tenant Risk Changes the Security Conversation
Cloud services are inherently multi-tenant, but the entire model depends on a straightforward promise: one organization’s tenant, identities, data, and workloads must remain isolated from another’s unless an administrator has deliberately established a governed trust relationship.That is why the most concerning aspect of the Azure Automation flaw is not simply privilege escalation. It is the reported ability, under the right conditions, to cross an Azure tenant boundary and assume or misuse another organization’s automation identity. Petri reports that the vulnerability could be combined with a risky default configuration and other application weaknesses to impersonate another organization’s automation identity.
Reporting from Dark Reading adds important technical context. Researcher Shay Shavit, a senior security researcher on Microsoft’s Azure Networking Security Research team, found that an attacker with access to an Azure Automation account could potentially breach the expected trust boundary and assume another tenant’s automation identity. From there, the attacker could potentially create or modify automation scripts, access configuration data or credentials held by Automation accounts, and manipulate cloud resources reachable by the compromised identity.
This is exactly the kind of failure mode that security architects fear in automation services. Automation is designed to act at machine speed and often operates without interactive human approval. If an identity entrusted to a runbook is compromised, the attacker may not need to steal a password, defeat multifactor authentication, or persuade a user to authorize a malicious application. They may instead inherit the capabilities already delegated to the automation layer.
A flaw in authorization, not a failure of encryption
It is worth separating this incident from common cloud-security shorthand. CVE-2025-29827 is not described as a cryptographic break, a TLS failure, or a password-disclosure bug. The core issue is authorization: whether the service correctly validates the requester, identifies the applicable tenant and identity context, and limits the requester to permissions they are actually supposed to hold.That difference matters operationally. Organizations can have strong encryption, multi-factor authentication, and modern endpoint protection while still being exposed if a cloud control plane incorrectly authorizes an operation or allows an identity assertion to cross a boundary it should never cross.
The official CVE record reflects that concern. Microsoft’s CVSS vector includes
S:C, or Scope Changed, indicating that exploitation could affect security authority beyond the vulnerable component’s original authorization scope. The same vector records high impacts to confidentiality and integrity, plus a lower—but still significant—availability impact.How Azure Automation Became a High-Value Target
Azure Automation’s practical strengths also explain why it is attractive to attackers. IT teams increasingly depend on automation for tasks that would otherwise require manual, privileged intervention:- Resource provisioning and deprovisioning
- Scheduled maintenance and update workflows
- VM start, stop, and recovery actions
- Configuration enforcement
- Inventory and monitoring tasks
- Credential rotation and secrets-related operations
- Hybrid infrastructure orchestration
- Incident-response or remediation runbooks
Microsoft’s managed identity guidance illustrates the model directly: an Azure Automation account can obtain tokens for other Microsoft Entra ID-protected resources, and those tokens represent the Automation account rather than a human user. Microsoft also explicitly advises assigning only the permissions a runbook needs—for example, VM start/stop rights rather than broad control-plane permissions, or read-only access when the task only reads blob storage. Microsoft Learn
This is an essential benefit of managed identities. They can eliminate embedded credentials and reduce secret-management overhead. However, managed identities do not make authorization design optional. They shift the security question from “Where is the password?” to “What can this non-human identity do, where, and under what conditions?”
The danger of overly broad automation identities
A managed identity granted Owner, Contributor, broad custom roles, subscription-wide rights, or unnecessarily powerful Microsoft Entra permissions becomes a potential blast-radius multiplier. If an attacker can impersonate, hijack, or cause a runbook to act through that identity, every excess permission becomes usable attack surface.Microsoft’s Azure Automation security guidance recommends granular Azure RBAC roles, discourages broad role assignments at subscription scope, and advises against wildcard actions in custom roles. It also notes that runbook-level role-based access should be used when a user does not need access to every runbook in an Automation account. Microsoft Learn
Those recommendations are not generic compliance boilerplate in the context of CVE-2025-29827. They are direct mitigations for the real-world impact of authorization failures. A platform-level fix can prevent the specific cross-tenant exploit path, but narrowly scoped roles still determine what a compromised or abused automation identity could do within its own environment.
The Role of the Default Public Configuration
The vulnerability’s reported exploitability became more serious because of a configuration posture that exposed an Automation-related endpoint by default. According to Dark Reading, the relevant Azure Automation identity endpoint had been public by default at the time the research was conducted, helping make the broader attack chain possible.The distinction between publicly reachable and insecure is important. Many Azure services provide public endpoints for legitimate reasons, including webhooks, cloud management, hybrid worker communications, and integrations. Public reachability is not automatically a vulnerability.
But public reachability becomes dangerous when it interacts with an authorization defect. A service may correctly expose an endpoint to enable automation from distributed systems, but if that endpoint accepts or processes identity-related requests without enforcing appropriate tenant, resource, and caller boundaries, the endpoint can become a gateway to a much larger compromise.
Microsoft has reportedly addressed both sides of the problem: the authorization flaw itself and the default configuration that contributed to exposure. Petri says Microsoft changed the default configuration as part of the remediation, while Dark Reading reports that Azure Automation identities are no longer public by default.
Secure defaults are a security control, not a convenience setting
This incident reinforces a central lesson for cloud-platform engineering: secure defaults have outsized defensive value.A secure default does not eliminate the ability to expose a service where needed. Instead, it makes exposure an intentional administrative choice that must be justified by a business workflow. That approach reduces the number of reachable assets, makes risky designs more visible during review, and gives organizations a clearer inventory of services that genuinely require public access.
For Azure administrators, the practical takeaway is that a configuration review should not stop at “is the CVE fixed?” It should also ask:
- Which Automation accounts still permit public network access?
- Which accounts expose webhooks?
- Which Hybrid Runbook Workers require internet access?
- Which runbooks execute with identities that can access sensitive data or make control-plane changes?
- Which accounts are integrated with production Key Vault, storage, virtual machines, or deployment workflows?
- Which permissions have accumulated over time without being revalidated?
Remediation in a SaaS Service Is Not the Same as Patch Tuesday
The wording around “patching” can be misleading for exclusively hosted services such as Azure Automation. Unlike a Windows Server vulnerability, where customers may need to deploy a KB update, restart systems, and validate version levels, a service-side Azure remediation is primarily implemented by Microsoft in the platform.The CVE record labels the issue as an exclusively-hosted-service vulnerability. That means enterprises should not expect a traditional operating-system patch for Azure Automation itself.
However, “Microsoft has fixed it” should not translate into “there is nothing for customers to do.” The platform remediation closes the identified defect, but customer-owned configuration remains customer-owned. Organizations still control the identities attached to Automation accounts, the RBAC roles they receive, the webhooks that invoke runbooks, the runbook content, network exposure, worker placement, and access-monitoring strategy.
This is a common cloud shared-responsibility reality. The provider must secure the service control plane and tenant-isolation mechanisms. The customer must reduce unnecessary privilege, eliminate stale accounts and runbooks, isolate sensitive workflows, and watch for signs that automation is being used in unexpected ways.
A Practical Azure Automation Security Review
The most useful response to CVE-2025-29827 is a focused review of Azure Automation trust relationships rather than a vague “check your cloud security” exercise.1. Inventory every Azure Automation account
Start by cataloging all Automation accounts across subscriptions and management groups. Include development, testing, lab, acquired-business, and legacy subscriptions. Automation often becomes invisible once it works reliably, which makes older accounts especially likely to retain broad privileges.For each account, identify:
- Its owners and administrators
- Active and disabled runbooks
- Published versus draft runbooks
- Linked source-control repositories
- Webhooks and their business purpose
- Hybrid Runbook Workers and their host systems
- System-assigned and user-assigned managed identities
- Azure role assignments
- Connections to Key Vault, storage, virtual machines, Azure Monitor, and other services
2. Reassess managed identity privileges
A runbook identity should have the smallest useful permission set, at the smallest practical scope. Microsoft specifically recommends following least privilege and ensuring that an identity which only needs to start or stop a VM receives only those rights, while a blob-reading task receives read-only access rather than write or management permissions. Microsoft LearnSecurity teams should pay particular attention to:
- Subscription-level Owner or Contributor assignments
- Broad custom roles containing wildcard actions
- Write permissions to production resource groups
- Privileged Microsoft Entra directory roles
- Key Vault access that allows secret retrieval or modification
- Rights to create or edit role assignments
- Rights to modify runbooks, webhook configuration, or source-control integration
3. Restrict public network exposure where feasible
Azure Private Link provides a way to connect to Azure Automation through private endpoints, using private IP addresses in a virtual network rather than exposing access through public networking. Microsoft states that this can keep traffic on the Azure backbone, prevent public network access, and limit Automation data access to authorized private networks. Microsoft LearnFor applicable Automation workloads, administrators can configure an Automation account to deny public configurations and allow connections only through private endpoints by setting the
publicNetworkAccess property to false. Microsoft LearnThere are design tradeoffs. Microsoft documents that, in the current implementation, Automation cloud jobs cannot access certain Azure resources secured through private endpoints, including Azure Key Vault, Azure SQL, and Azure Storage; it points to Hybrid Runbook Workers as the workaround for those scenarios. Microsoft Learn This limitation means private networking should be planned as an architecture decision, not applied blindly in production.
4. Treat webhooks as privileged entry points
A webhook can start a runbook through an HTTP POST request. That is useful for event-driven automation, but it also means that webhook URLs, tokens, caller restrictions, and runbook parameters deserve the same review normally given to application APIs. Microsoft LearnSecurity teams should determine whether each webhook remains necessary and whether it can be replaced with a more strongly authenticated workflow. They should also ensure that runbooks triggered through webhooks do not accept uncontrolled inputs that can alter resource targets, subscription contexts, scripts, or identity behavior.
5. Harden and monitor Hybrid Runbook Workers
Hybrid Runbook Workers expand Azure Automation into Azure VMs, on-premises servers, and Azure Arc-enabled machines. This is useful for managing systems that cloud-hosted jobs cannot reach, but it also connects cloud automation privileges with server-level execution environments. Microsoft LearnMicrosoft warns that a user with VM Contributor rights or permissions to run commands on an unrestricted Hybrid Worker machine could potentially obtain Automation credentials and gain access equivalent to a subscription contributor. It also strongly advises against placing the Hybrid Worker extension on a domain controller. Microsoft Learn
That guidance should be treated as a high-priority architectural rule:
- Do not host Hybrid Workers on domain controllers.
- Do not use broadly accessible shared administration servers as privileged workers.
- Remove unused or unresponsive workers.
- Limit who can run commands on worker machines.
- Segregate workers based on environment sensitivity.
- Monitor worker hosts for unusual PowerShell, credential-access, or role-assignment activity.
Detection and Incident-Response Implications
There have been no known exploits of CVE-2025-29827 reported in the available coverage, according to Shay Shavit’s comments to Dark Reading. That is encouraging, but it does not reduce the value of retrospective investigation—particularly in environments where Automation accounts have had public exposure and highly privileged identities.Security operations teams should review historical activity for unexpected changes involving Automation accounts, managed identities, runbooks, and role assignments. The goal is not to search for one known exploit signature but to find anomalous actions that would be meaningful if an automation identity had been misused.
Priority review areas include:
- Newly created, modified, or deleted runbooks
- Unusual runbook publication events
- New or altered webhook configurations
- Unexpected managed-identity role assignments
- Changes to Key Vault policies or secret access patterns
- Automation accounts created in unusual subscriptions or regions
- Cross-tenant access activity that lacks a documented business relationship
- New source-control integrations or unexpected repository changes
- Privileged resource deployment or deletion activity initiated by automation identities
Strengths of Microsoft’s Response—and the Remaining Risks
The most important positive development is that Microsoft reportedly remediated the underlying authorization weakness and changed the default configuration associated with the cross-tenant risk. Petri Fixing both the implementation defect and the exposure-friendly default is materially stronger than addressing only one link in the chain.The severity rating also deserves credit. A 9.9 critical score communicates that the potential impact was not a routine permission edge case. Microsoft’s CVSS assessment explicitly recognizes a low-privilege remote attack path with a changed scope and high confidentiality and integrity impact. NVD
Yet the incident also exposes an enduring cloud-security risk: organizations often invest heavily in preventing initial access while giving insufficient attention to the non-human identities that run their infrastructure. A compromised user account is visible and familiar. A compromised automation identity can be quieter, more persistent, and more dangerous because it is expected to execute scripts and make changes.
Azure Automation remains a powerful and legitimate platform for Windows administrators, cloud engineers, and enterprise operations teams. The correct response is not to abandon it. It is to operate it as privileged infrastructure: minimize identity permissions, restrict public access, isolate worker systems, secure webhook paths, review every trust relationship, and log enough context to detect when automation starts doing something that automation was never meant to do.
CVE-2025-29827 is therefore more than a single Azure Automation vulnerability. It is a reminder that in modern cloud environments, automation identities are administrators, and every administrative identity must be designed, constrained, monitored, and defended accordingly.
References
- Primary source: Petri IT Knowledgebase
Published: 2026-07-27T13:15:58+00:00
Microsoft Fixes Critical Azure Automation Privilege Escalation Flaw
Microsoft has fixed a critical Azure Automation flaw that could allow privilege escalation and potential access to resources across Azure tenants.
petri.com
- Referenced source: cve.org
- Related coverage: darkreading.com
Default Azure Automation Setting Enables Cross-Tenant Attacks
A critical Azure Automation bug lets an attacker with a valid account hijack identities and access other tenants' data, credentials, and cloud workloads.www.darkreading.com - Related coverage: pulse.adyog.com
Default Azure Setting Let One Tenant Take Another's Identity — adyog
A default Azure Automation setting let one tenant assume another's identity — CVSS 9.9, patched silently, no customer action required.pulse.adyog.com - Related coverage: learn.microsoft.com
Azure Automation security guidelines, security best practices Automation jobs. | Microsoft Learn
This article helps you with the guidelines that Azure Automation offers to ensure a secured configuration of Automation account, Hybrid Runbook worker role, authentication certificate and identities, network isolation and policies.learn.microsoft.com - Related coverage: azure.microsoft.com
