# Azure Automation's Public-by-Default Flaw Let Attackers Hijack Identities Across Tenant Boundaries


## The Threat


A near-perfect CVSS score doesn't always mean what you think it means. CVE-2025-29827 isn't a buffer overflow or a code execution bug in the traditional sense — it's something arguably more insidious: a default configuration that made Azure Automation account identities publicly discoverable, combined with a chain of code flaws that let any authenticated Azure user cross tenant boundaries and impersonate another organization's automation identity entirely.


Azure Automation sits at the heart of modern cloud operations. Enterprises use it to run scripted runbooks that handle secrets rotation, resource deployment, patching cycles, and DevOps pipelines — all tied to managed identities that carry real permissions inside Azure. Microsoft itself relies on it internally. When an attacker can walk into your tenant, assume your automation identity, and start modifying or creating runbooks, they're not just reading data — they're operating as you, with your credentials, against your cloud workloads.


The vulnerability was discovered by Shay Shavit, a senior security researcher on Microsoft's Azure Networking Security Research team, who reported it to the Microsoft Security Response Center. The MSRC has since issued an advisory and patched both the default configuration and the underlying code flaws. Shavit reports no known exploitation in the wild, but plans to demonstrate the full attack chain at Black Hat USA next month in Las Vegas — which means the clock is ticking for organizations that haven't verified their posture.


## Severity and Impact


| Field | Detail |

|---|---|

| CVE | CVE-2025-29827 |

| CVSS Score | 9.9 (Critical) |

| Vulnerability Type | Elevation of Privilege |

| CWE | CWE-276 (Incorrect Default Permissions) |

| Attack Vector | Network |

| Attack Complexity | Low |

| Authentication Required | Yes (attacker needs their own Azure account) |

| Scope | Changed — crosses tenant trust boundary |

| Confidentiality / Integrity / Availability Impact | High / High / High |


The 9.9 score reflects the changed scope: an attacker operating within their own legitimate Azure tenant can breach the isolation boundary and act within a victim's tenant. That's the worst possible outcome in a shared-cloud model — tenant isolation is supposed to be the foundational guarantee.


## Affected Products


  • Microsoft Azure Automation — all accounts where the automation account endpoint was configured with the default public visibility setting
  • Organizations using Azure Automation for:
  • - DevOps pipelines and resource deployment

    - Automated patching and compliance workflows

    - Secrets rotation tied to managed identities

    - Cloud workload orchestration via runbooks


    Microsoft has remediated the default configuration globally. The endpoint visibility default is no longer public. However, accounts created before the fix may have operated under the vulnerable default for an extended period.


    ## Mitigations


    Immediate actions:


  • Confirm your Azure Automation accounts are not using legacy public endpoint configurations — review network access settings in the Azure portal under each Automation account
  • Audit managed identity permissions attached to Automation accounts and apply least-privilege scoping
  • Review runbook history for unexpected modifications, especially any runbooks touching credential stores, key vaults, or cross-resource operations
  • Enable Azure Monitor alerts on Automation account changes and identity assignments

  • Strategic hardening:


  • Restrict Automation account endpoints to private network access using Azure Private Link where feasible
  • Enable Diagnostic Settings on all Automation accounts to log job streams and configuration changes to a centralized SIEM
  • Rotate any credentials or secrets stored in Automation accounts as a precaution — treat them as potentially exposed during the vulnerability window
  • Apply Azure Policy to enforce private endpoint requirements for new Automation account creation going forward

  • Microsoft's patch addresses both the default configuration and the code-level flaws in the chain. No customer-side code change is required to receive the fix, but configuration review is still essential.


    ## References


  • [Microsoft Security Advisory — CVE-2025-29827](https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-29827)
  • [Dark Reading: Default Azure Automation Setting Enables Cross-Tenant Identity Takeover](https://www.darkreading.com/)
  • [Black Hat USA 2026 — Shay Shavit Session Preview](https://www.blackhat.com/)
  • [Microsoft Azure Automation Documentation](https://learn.microsoft.com/en-us/azure/automation/)

  • ---


    ## HackWire Analysis


    The framing of this vulnerability as a "default configuration problem" lets Microsoft off easy. This isn't a case where an admin accidentally checked the wrong box — this was the out-of-the-box behavior for every Azure Automation account created during the vulnerable period. Public endpoint visibility was the default. That's a product decision, not a user error.


    What makes CVE-2025-29827 worth watching beyond the patch cycle is what it reveals about the attack surface of managed identities at scale. Automation accounts are essentially privileged bots. They carry identities that can create, modify, and delete Azure resources. When the discovery mechanism for those identities is public by default, you've handed attackers a directory of high-value targets with a roadmap to impersonation built in. The code flaws that completed the exploit chain are almost secondary — the enumeration problem was the door.


    The Black Hat demonstration next month will matter. Shavit's ability to show the full chain live means defenders will finally have concrete proof-of-concept detail to pressure their internal cloud teams for remediation verification — not just "Microsoft says they patched it." Organizations running large Azure estates with many Automation accounts, particularly those using them for secrets rotation, should treat this as an active threat modeling exercise, not a checkbox.


    There's also a pattern worth naming: cloud providers consistently underweight the security implications of their default configurations. This is the same failure mode that produced public S3 buckets, open Cosmos DB instances, and misconfigured Azure Blob Storage endpoints. The technology changes; the root cause stays the same.


    — HackWire Editorial


    ## Related Coverage


  • Read more in our [Vulnerabilities](https://www.hackwire.news/category/vulnerabilities) coverage
  • Cross-reference with [Breaches](https://www.hackwire.news/category/breaches) and [Malware](https://www.hackwire.news/category/malware)
  • Stay current via the [HackWire homepage](https://www.hackwire.news/)