Summary
- CVE-2025-29827 allowed researchers to cross an Azure Automation trust boundary and assume another tenant’s managed identity.
- Microsoft changed the public default and corrected the service-side flaws; no known exploitation has been reported.
- Broadly privileged automation identities can extend the effect of a managed-service weakness across workloads, credentials, and administrative resources.
A vulnerability in Azure Automation allowed Microsoft researchers to cross a cloud-tenant boundary and assume an identity belonging to another customer, exposing a route from a managed service into highly privileged non-human access.
Microsoft assigned CVE-2025-29827 to the issue and rated it 9.9 under CVSS. The company corrected the vulnerability in 2025, while fuller technical details are due to be presented at Black Hat USA in August 2026.
Azure Automation enables organisations to run scheduled and event-driven processes for resource deployment, patching, credential rotation, configuration, and other administrative work. Those runbooks can use managed identities to act across Azure without storing conventional usernames and passwords inside scripts.
The research combined three conditions: a default configuration that made an Automation account endpoint publicly accessible and two flaws in the service’s implementation. An attacker required access to an Azure Automation account of their own but could then breach the service’s trust boundary and assume an identity associated with another tenant.
The resulting access would depend on the permissions assigned to the victim identity. A highly privileged automation account could allow an attacker to create or alter runbooks, read sensitive configuration and credentials, or create, modify, and delete resources across connected subscriptions.
Microsoft changed the public default and applied a server-side correction. The company has not reported evidence of exploitation, and customers did not need to deploy a conventional software patch. Its security advisory remains the formal record of the vulnerability.
The remediation addressed the service defect, although organisations still need to examine the permissions attached to their automation identities. Managed identities reduce the need to distribute static credentials, but their access can expand as new runbooks, subscriptions, and operational functions are added.
An identity created for a narrow maintenance task may eventually receive access to production subscriptions, secret stores, deployment systems, backup environments, or network controls. Those permissions define the effect of a compromise even when the initial weakness sits inside the provider’s managed service.
Non-human identities can also fall outside established joiner, mover, and leaver processes. Some lack a named business owner, a scheduled access review, or the interactive login patterns used by identity-monitoring systems to identify unusual behaviour.
The cross-tenant element places a separate responsibility on the provider. Customers cannot inspect or correct Microsoft’s internal service implementation, while tenant isolation is expected to operate below the level of customer-managed configuration.
Organisations can still reduce potential exposure by limiting the scope of automation identities, separating development and production accounts, restricting public endpoints where they are unnecessary, and monitoring changes to runbooks, role assignments, and managed identities.
Automation accounts should not receive broad subscription-level permissions solely to simplify deployment. Assigning narrowly scoped roles to individual functions can limit the resources available if a runbook, service endpoint, administrator, or provider control is compromised.
Historical investigation may be more difficult where the service itself crosses the trust boundary. Logs recording later resource actions could show the legitimate managed identity without revealing how another tenant obtained it, leaving customers dependent on provider telemetry to establish whether the service flaw was used.
Microsoft’s Black Hat session, titled “Handle With Care: Chaining Azure Automation Flaws for Cross-Tenant Identity Takeover”, is expected to provide a fuller technical sequence. The vulnerability was corrected before that presentation and is not known to have been exploited.
The affected architecture remains common across cloud estates: managed services hold identities capable of administering large environments, while many of the controls enforcing isolation are operated entirely by the provider. Limiting the authority of each automation identity reduces the amount of infrastructure placed behind any single trust boundary.
