Microsoft has released a security update to plug a high-severity vulnerability in the Azure Connected Machine agent—the component that links on-premises and hybrid servers to Azure Arc. The flaw, tracked under CVE-2025-58724 and several other identifiers, lets an authenticated local attacker escalate privileges to SYSTEM (or root on Linux), potentially giving them the keys to cloud-managed identities, extensions, and management plane trust.

For admins relying on Azure Arc to govern thousands of servers, this isn't just another patch—it's an urgent fix with implications that ripple across hybrid estates. The good news: the vulnerability is local, not remotely exploitable without a foothold. The bad: once inside, an attacker can weaponize it to pivot into the cloud and take control of critical management functions.

The Vulnerability at a Glance

The bug is an improper access control issue (CWE-284) in the Azure Arc agent, commonly called azcmagent. According to the Microsoft Security Response Center, a low-privileged local user can exploit weaknesses in how the agent enforces permissions on its privileged services—think the Hybrid Instance Metadata Service (HIMDS), installer routines, or extension management—to run arbitrary code in a high-privilege context.

Security trackers have assigned this flaw multiple CVE numbers: CVE-2025-58724 in some feeds, alongside earlier identifiers like CVE-2025-26627 and CVE-2025-49692 that describe closely related issues. This fragmentation is the result of how different vulnerability databases and community feeds catalog the same underlying problem, and it’s more than a clerical headache—automated patching tools that filter by CVE number can miss the fix entirely if they aren’t pointing at the right advisory-to-package mapping.

The CVSS severity score hovers around 7.0–7.8 (High), reflecting the local attack vector paired with devastating impact: the agent runs with system privileges and holds implicit trust within Azure’s management plane, making it a juicy target for attackers looking to escalate from a local foothold to cloud-level compromise.

Who's at Risk and Why

If you’re running Azure Arc on Windows or Linux servers—whether to monitor, manage, deploy extensions, or enable machine-assigned managed identities—you’re in the blast radius. The risk isn’t just for the compromised host; it’s a force multiplier. A successful escalation can lead to:

  • Managed identity abuse: The attacker can request tokens from the local HIMDS endpoint, using machine-assigned identities to access Azure resources like Key Vaults, storage accounts, or databases.
  • Extension takeover: Arc’s extension framework lets attackers push malicious extensions or tamper with legitimate ones, creating deep persistence.
  • Management plane pivot: If the compromised host is a jump box, bastion, or CI/CD runner, the attacker can use the elevated access to move laterally across your hybrid environment.

Home users and pure cloud-only VMs aren’t directly affected—the Arc agent is optional and typically deployed on servers that need hybrid governance. But for enterprises, this is a high-priority fix, especially on servers that hold sensitive credentials, run shared workloads, or sit at network edges.

How We Got Here

The Azure Arc agent has become a cornerstone of Microsoft’s hybrid strategy, bridging on-premises data centers, edge sites, and multi-cloud servers with Azure’s control plane. As its role expanded, so did its attack surface. The agent exposes local HTTP endpoints (like HIMDS), manages scheduled tasks and services, and must run with elevated privileges—often as SYSTEM on Windows. That makes it a red team’s dream for local privilege escalation.

This isn’t the first time a management agent has been at the center of such a vulnerability. The cybersecurity community has long warned about the risks of agents that run with high privileges and accept commands from less-trusted actors. In recent months, multiple CVE IDs have popped up for Azure Arc agent issues, some describing command-injection vulnerabilities in installer flows. The fragmentation of identifiers reflects an ongoing challenge: Microsoft’s own advisory and third-party trackers don’t always align on which CVE covers which update, forcing defenders to do extra homework.

The current flaw came to light through Microsoft’s monthly security update process. The MSRC advisory (first published in early April 2025, with updates as late as mid-May) confirms that a local authenticated attacker could exploit it. No proof-of-concept exploit code has been seen in the wild yet, but given the accessibility of the bug class—improper access control and command injection are well-trodden paths—weapons could surface quickly.

What to Do Now: A Practical Fix Guide

1. Inventory your Arc agents immediately

If you haven’t already, run an Azure Resource Graph query to see every Arc-connected machine and its agent version. Here’s a starter Kusto query:

resources
| where type == "microsoft.hybridcompute/machines"
| extend agentVersion = properties.agentVersion
| project name, agentVersion, resourceGroup, subscriptionId
| order by agentVersion asc

Prioritize machines with older agent versions and those that serve as jump hosts, management servers, CI/CD runners, or any server with a machine-assigned managed identity.

On individual hosts, you can check the version locally by running azcmagent version in an elevated command prompt or terminal.

2. Patch to the latest agent version

Microsoft has released a security update for the Azure Connected Machine agent. The fix is available via Microsoft Update, the Microsoft Update Catalog, or by downloading the latest MSI from the official documentation. Unfortunately, the advisory page we reviewed (CVE-2025-58724) doesn’t disclose a specific fixed version number publicly—the page renders dynamic content—so you’ll need to consult the Security Update Guide directly or the agent release notes.

The rule of thumb: update to the most recent Generally Available build. After patching, verify the agent version again (azcmagent version) and re-run your Resource Graph query to confirm no holdouts.

Critical: Do not rely solely on a single CVE number to gate your patch deployment. The same fix may be indexed under multiple identifiers across different trackers. Map by vendor advisory KB/package and the agent version string instead.

3. Compensating controls if you can’t patch right away

If you can’t roll out the patch within 24–72 hours, harden your environment:

  • Restrict local access to agent control endpoints (e.g., limit who can run azcmagent commands, tighten host firewall rules to block untrusted users from accessing HIMDS).
  • For Windows, enforce AppLocker or Windows Defender Application Control to prevent unauthorized binaries from launching the agent.
  • Disable unused machine-assigned managed identities temporarily if you can’t patch routers and jump boxes.
  • Harden CI/CD runners: require signed scripts, restrict installer privileges, and use ephemeral build agents when possible.

4. Hunt for signs of compromise

Even if you patch now, assume an attacker may have already exploited the bug. Look for these indicators in your SIEM and EDR:

  • Unexpected azcmagent.exe or azcmagent process launches with a parent process that isn’t a typical installer or admin tool.
  • Command-line arguments containing shell metacharacters (;, &&, `) in azcmagent-related events.
  • Unusual requests to localhost HIMDS endpoints (ports 40342 and 40343) from non-system accounts.
  • Sudden creation of new scheduled tasks or services that mimic the agent’s naming conventions.
  • Anomalous token retrieval spikes from Arc-managed machines in your Azure AD / Entra ID logs.

If you find evidence of exploitation, isolate the host, rotate its managed identity credentials, revoke any active tokens, and launch your incident response playbook.

Detecting Future Attempts

Integrate Azure Arc-specific detections into your security monitoring:

  • EDR rules: Flag any azcmagent.exe execution from non-standard paths or by non-admin users.
  • Host firewall logs: Monitor outbound connections from Arc-agent processes that aren’t to known Azure IP ranges.
  • Extension installation logs: Use the Arc extension manager logs to spot suspicious extensions that don’t match your deployment schedule.

If you use Microsoft Sentinel or Defender for Cloud, enable the built-in Azure Arc data connectors and create custom analytics rules for the above scenarios.

Outlook: Keep an Eye on the CVE Merry-Go-Round

The fragmentation of CVE identifiers isn’t going away. In the coming weeks, expect Microsoft and various threat intelligence platforms to potentially consolidate or remap the identifiers associated with this flaw. Subscribe to the MSRC Security Update Guide for CVE-2025-58724 and monitor the Azure Arc agent release notes for any post-patch hotfixes.

More importantly, watch for proof-of-concept code. The class of vulnerability is well understood, and once a researcher publishes exploit details—or attackers reverse-engineer the patch—the risk of in-the-wild exploitation rises sharply. Your patching window is now.

The Bottom Line

This Azure Arc agent vulnerability is a textbook local privilege escalation with modern hybrid-cloud consequences. By patching swiftly, auditing your agent versions, and tuning your detection pipelines, you can shut the door before attackers walk through it. The key is to act on the fixed agent version, not just a CVE number, and to treat every Arc-enabled server as a high-value target in your patching schedule.