Microsoft has patched a high-severity vulnerability in its Azure Connected Machine agent that could allow a limited user to gain complete control over a server—and potentially the cloud resources tied to it. The flaw, tracked as CVE-2025-58724, was disclosed this week and affects all Arc-enabled Windows and Linux machines running an outdated version of the azcmagent software. Organizations using hybrid management should treat this as a priority fix.

What Microsoft Fixed

The security update addresses an elevation-of-privilege bug in the Azure Arc agent installer and local components. Microsoft’s advisory describes it as an improper input neutralization flaw, where specially crafted input can be injected into a privileged command line. In practical terms, a standard user on a server who triggers certain agent functions could append malicious commands that run with SYSTEM-level rights on Windows or root on Linux.

The vulnerability is local, meaning an attacker must already have code execution on the target machine. However, that’s a low bar in modern attack chains: phishing, malicious software, or a compromised CI/CD pipeline can all provide that initial foothold. Once elevated, the attacker can install persistent malware, disable defenses, and—critically—abuse the Arc agent’s built-in managed identity tokens to access cloud resources like Azure Key Vaults or storage accounts.

Microsoft released the fix through its standard update channels. The patched agent build is available via Windows Update, the Microsoft Update Catalog, and as a standalone MSI installer. The company urges all customers to upgrade immediately. Azure Resource Graph queries can quickly identify affected agent versions across an estate; the azcmagent version command returns the installed build on individual hosts.

There’s an added wrinkle: vulnerability databases have assigned slightly different CVE identifiers to what appears to be the same underlying issue. While Microsoft uses CVE-2025-58724 in its Security Update Guide, some third-party trackers list it under CVE-2025-60724 or other internal IDs. This fragmentation can break automated patching tools that rely on a single CVE number. Defenders should always map to the vendor’s official KB and agent version, not just a CVE label.

Who’s at Risk and Why This Bug Is Different

Most local privilege escalation bugs are a dime a dozen, but this one matters far more because of what the Arc agent is. It is the software bridge that connects your on-premises and edge servers to Azure’s management plane. When you install the agent, you grant it the ability to enforce policies, deploy extensions, and—most critically—handle machine identity. The agent exposes a local metadata endpoint (HIMDS) that, when called, can request access tokens for Azure managed identities. In a hybrid cloud setup, those identities often hold significant permissions.

Consider a typical enterprise scenario: a jump box or bastion host that administrators RDP into daily. That machine is enrolled in Azure Arc for monitoring and patch compliance. A standard user—perhaps an intern or a contractor—logges in with limited privileges. Through a simple exploit of this bug, that user escalates to SYSTEM, then queries the local metadata service for an access token. That token might grant them a service connection to read secrets from Key Vault, push code to a production container registry, or even start virtual machines in Azure.

For CI/CD runners and build servers, the risk is similarly elevated. These systems frequently run unverified code from pull requests. An attacker who slips a malicious package into a build job could exploit the flaw to break out of the runner environment and compromise the entire host. If the host is running the Arc agent with a machine-assigned managed identity, the attack can quickly pivot to cloud infrastructure. This isn’t theoretical: the same class of bug has been used in several sophisticated supply-chain attacks.

Home users and small-scale developers are essentially unaffected, unless they’ve explicitly set up Arc for learning or hybrid cloud experiments. For them, the fix is simple and low-priority. For enterprise admins, this vulnerability should jump to the top of the patch list.

The Fragile Bridge Between Cloud and Server

Azure Arc was designed to simplify hybrid management. Instead of juggling multiple tools, IT teams can use a single Azure portal to oversee servers in their own data center, on AWS, or at the edge. The Connected Machine agent (azcmagent.exe on Windows) is the linchpin. It installs as a set of services, runs with high privilege, and opens a control channel to Azure. That same agent also has local interfaces—command-line utilities, PowerShell modules, a REST metadata service—that other applications and users can interact with.

The flaw in this month’s advisory sits squarely in those local interfaces. Microsoft has not published the full technical breakdown, but community analysis points to command injection in the installer scripts. When the agent processes certain parameters or input files, it fails to sanitize special characters. An attacker can craft that input to break out of the intended command and append their own. The result: code that runs with the agent’s elevated privileges.

This isn’t the first time a management agent has been a security liability. Similar tools from other vendors have fallen prey to the same class of bug. The underlying problem is architectural: agents must straddle the line between local system access and remote orchestration, and any slip in input validation on either side can be exploited. In Arc’s case, the added complication of managed identity token issuance turns a local elevation into a potential cross-provider breach.

The CVE fragmentation only adds to the confusion. Several vulnerability databases assigned their own identifiers before Microsoft published CVE-2025-58724. That means a vulnerability scanner that queries a third-party API might show a different number, or consider the machine patched when it isn’t. Security teams who rely on automated workflows to approve patches based on CVE alone could miss this update entirely.

Your Action Plan: Patch, Harden, Detect

Here is a concrete, four-step sequence to eliminate the risk and improve your posture going forward.

Step 1: Find and Verify

Find every machine running the Azure Connected Machine agent. The fastest method is Azure Resource Graph. Open the Azure portal, navigate to Resource Graph Explorer, and run:

resources
| where type =~ 'microsoft.hybridcompute/machines'
| extend agentVersion = properties.agentVersion
| project name, agentVersion, resourceGroup, subscriptionId

This returns the agent version for each Arc-connected machine. Cross-reference that version against the fixed build listed in Microsoft’s advisory (available on the MSRC page for CVE-2025-58724). If you manage a fleet without direct Azure connectivity—say, in an air-gapped network—log onto each server and execute azcmagent version. The output is the installed agent version.

Step 2: Apply the Fix

Deploy the patch through your normal software update channel. The fixed agent is available via:

  • Windows Update: The agent is offered as an optional update; check for it manually or approve it in WSUS.
  • Microsoft Update Catalog: Download the MSI package and deploy with SCCM, Intune, or any third-party tool.
  • Direct MSI download: From the official Azure Arc documentation page; useful for Linux with package managers like apt or yum.

After updating, confirm by re-running the Resource Graph query or the azcmagent version command. If your environment requires change control windows, start the process immediately—the risk is acute.

Step 3: Shield Systems You Can’t Patch Yet

If patching must wait, implement compensating controls:

  • Restrict installer execution: Use Windows Defender Application Control (WDAC) or AppLocker to block standard users from running the Arc agent installer. Create a policy that only permits trusted administrator accounts to modify %ProgramFiles%\AzureConnectedMachineAgent.
  • Harden the metadata endpoint: The HIMDS listens on port 40342. Use host firewall rules (Windows Firewall or iptables) to block non-system processes from connecting to localhost:40342. On Windows, a simple outbound rule scoped to local addresses and specific user accounts can prevent unauthorized token requests.
  • Isolate CI/CD runners: If build jobs must run on Arc-enabled machines, ensure they execute under dedicated low-privilege service accounts. Apply network policies that limits outbound connections from those accounts, and disable the agent entirely on runners that don’t require hybrid management.
  • Lock down managed identities: Review every machine-assigned identity in Azure. Remove any identity that grants more access than absolutely necessary. For high-impact systems, consider disabling managed identity authentication and requiring explicit credential retrieval through a secrets manager.

Step 4: Watch for Exploitation Attempts

Even with the patch, assume a determined attacker may already be inside. Enhance your monitoring:

  • Collect agent logs: On Windows, the agent writes to %ProgramData%\AzureConnectedMachineAgent\Log. Ship these files to your SIEM or log analytics workspace. Linux paths vary, but are typically under /var/opt/azcmagent/log.
  • Create detection rules for the following patterns:
  • Process creation events where azcmagent.exe is called with command-line arguments containing shell metacharacters (;, &&, |, $())—a strong sign of injection.
  • Unexpected parent-child relationships: the himds.exe or extension management binaries spawning a shell or PowerShell.
  • Network connections from non-system processes to the HIMDS local endpoint (127.0.0.1:40342) that request identity/oauth2/token.
  • Use EDR to mine process trees: If a standard user account spawns whoami or net user immediately after an agent-related event, that’s a red flag.
  • Monitor cloud activity: In Azure AD, flag any sign-ins or token usage from managed identities that deviate from the normal pattern—for example, a development machine identity suddenly reading the production Key Vault.

If You’ve Already Been Hit

Contain, preserve, and escalate. Isolate the compromised machine from the network but keep it powered on. Collect forensic snapshots: process memory, disk, and agent logs. Assume the machine’s managed identity is burned: rotate every secret that identity could have accessed. Force a password reset for all users who have RDP’d to that host recently. Then, follow your incident response playbook for cloud pivoting scenarios.

Securing the Edge Against Future Attacks

The Azure Arc ecosystem will grow, and so will its attack surface. Microsoft regularly updates the agent, and each update may fix new vulnerabilities. Treat the agent like any critical infrastructure service: include it in your vulnerability scanning scope, enforce least-privilege installation, and centralize its telemetry.

Automation is your friend. Write an Azure Policy that triggers a non-compliance alert if agentVersion falls below the latest known good build. Use Azure Automation or a GitHub Actions workflow to run the Resource Graph inventory daily and email a report to the security team. When the next Arc-related CVE drops—and there will be a next one—you’ll already have the visibility you need.

Finally, do not rely on any single CVE number to determine if you are patched. Bookmark the MSRC page for CVE-2025-58724 as your source of truth, and cross-reference any scanner findings with the actual agentVersion installed. By anchoring your security process to the vendor’s advisory and not a third-party label, you avoid the confusion that has already led some teams to skip this critical update.

This patch is straightforward, but the risk it closes is not. Every hour an outdated agent runs on a hybrid server is an hour that a local account could become an admin—and that admin could reach into your cloud and take whatever they want. Don’t let a simple installer bug hand over the keys to your kingdom.