CVE-2026-26117: Azure Arc Windows LPE Cloud Identity Takeover

A chain of flaws in the Azure Arc / Azure Connected Machine agent for Windows can let a low‑privileged local user hijack agent service communications, impersonate the machine’s cloud identity, escalate to NT AUTHORITY\SYSTEM and — in the worst case — cause the machine to register to an attacker‑controlled tenant, exposing both host and cloud resources to compromise. (cymulate.com) (cvefeed.io)

Background​

Azure Arc’s Connected Machine agent (commonly packaged as azcmagent) is the on‑host component that links on‑premises or third‑party cloud servers into the Azure control plane. When an on‑prem or multi‑cloud server is “Arc-enabled” it receives an Azure resource object and a machine identity that can be used for configuration management, extension deployment, RBAC‑controlled resource access, telemetry and automated maintenance workflows. That powerful bridge between local hosts and Azure also concentrates trust: local services on the machine are responsible for protecting the machine’s cloud identity and mediation of agent‑to‑cloud communications. (cymulate.com)
On March 10, 2026 Microsoft (via its security tracking) and multiple independent vendors catalogued a new elevation‑of‑privilege entry, tracked as CVE‑2026‑26117, describing an authentication bypass using an alternate path or channel in the Azure Windows Virtual Machine / Connected Machine agent that allows an authorized local attacker to elevate privileges locally. Public scoring published alongside the entry sets a CVSS v3.1 base score at 7.8 (High). (cvefeed.io)
While Microsoft’s own Security Update Guide is the authoritative advisory, independent vendors and research labs published technical write‑ups and proof‑of‑concept details that clarify the exploitation chain — notably a local pre‑binding and service impersonation race that targets inter‑service listeners (HTTP or named pipes) used by Arc agent services on Windows. (cymulate.com)

---

What the advisory says (summary of the vendor record)​

• The publicly tracked issue is recorded as CVE‑2026‑26117 and described as an authentication bypass / improper access control in the Azure Windows Virtual Machine Agent / Azure Connected Machine Agent. (cvefeed.io)
• The vulnerability is local — Microsoft’s entry and subsequent trackers indicate the attack vector is local (not remotely exploitable over the network without initial local access). It has been scored with a CVSS v3.1 base of 7.8, reflecting the high impact on confidentiality, integrity and availability if successfully exploited. (cvefeed.io)
• Microsoft’s guidance: update the Azure/Arc agent to the latest fixed version and restart the agent services. Independent researchers and vendors confirm the vendor‑supplied remediation and recommend rapid agent upgrades. (cvefeed.io)

Note: Microsoft’s Security Update Guide entries for Arc/azcmagent CVEs can sometimes be terse; defenders should map the CVE to specific agent package builds and to the agentVersion reported by Arc resources before rolling out wide automation. Independent coverage and vendor release notes are therefore essential to verify which builds are fixed in which agent packages. (cymulate.com)

---

Technical analysis — how the chain works​

High‑level mechanics​

Independent analysis by Cymulate Research Labs and the ReverseC team provides the clearest public technical picture: the bug chain exploits service initialization order and weak local IPC protections to impersonate critical Arc services (Hybrid Instance Metadata Service — HIMDS — and related helper services). The attack uses three interlocking weaknesses:

• Delayed service startup: Arc agent services on Windows are often configured for delayed start. An attacker with low privileges can race the startup sequence, binding to ports or named pipes before the real service opens them, effectively “winning” the listener and impersonating the service. (cymulate.com)
• Unprotected local listeners: Some internal agent interactions happen over non‑TLS HTTP or unauthenticated named pipes. Where integrity and encryption are absent or infeasible, a pre‑bound malicious listener can accept and respond to requests that the agent expects from a legitimate service, supplying attacker‑controlled responses. (cymulate.com)
• Insufficient validation of service identity and inputs: The agent’s logic for validating the identity of the HIMDS/agent component and the authenticity of responses was insufficient in places, enabling the attacker to inject crafted replies that influence downstream behavior — including machine identity operations, updates and extension management. (cymulate.com)

Because the Arc agent is charged with validating and renewing the machine’s Azure identity, hijacking those inter‑service channels lets an attacker impersonate the machine to the cloud and perform management operations that the machine object is permitted to perform — e.g., modify machine attributes, request tokens for cloud APIs or deploy extensions. This elevates the impact from a local host compromise to a possible cloud resource compromise. (cymulate.com)

Concrete exploit steps (public PoC patterns)​

ReverseC’s advisory and follow‑ups outline a practical exploitation sequence used in lab PoCs:

• Wait for or trigger a device restart (exploitation relies on service startup ordering).
• Prior to the targeted Arc services starting, create and bind a malicious named‑pipe or HTTP listener that the service expects (HIMDS / azcmagent listeners). (labs.reversec.com)
• Respond to incoming requests in a way that causes the agent to accept attacker‑controlled installer URLs, tokens or commands (for example, forcing an update flow to download and execute a malicious MSI). (labs.reversec.com)
• Use the resulting code execution and privileged agent actions to escalate local privileges (to SYSTEM) and to obtain or manipulate the Azure identity associated with the machine. (cymulate.com)

ReverseC’s write‑up shows a scheduled update / msiexec repair path where the agent’s update scand executes it without robust integrity checks under certain error conditions. The vendor patch hardened the named pipe ownership checks to avoid interacting with rogue owners. (labs.reversec.com)

---

Impact: why defenders must treat this urgently​

This vulnerability is particularly concerning for three reasons:

• Bridge to cloud privileges: Arc‑joined machines carry Azure resource objects and may hold RBAC privileges. Compromising the agent can let an attacker perform cloud operations as the machine object — a lateral escalation from a local host compromise to cloud resource manipulation. (cymulate.com)
• SYSTEM escalation + persistence: The exploitation chain can yield NT AUTHORITY\SYSTEM on the host, enabling evasion of endpoint controls and persistent footholds. (cymulate.com)
• Wide deployment surface: Azure Arc is used to manage many on‑prem and multi‑cloud servers in enterprises. Unpatched agent instances increase the blast radius: a single compromised machine with broad RBAC privileges can cause cascading impacts. Community discussion and incident playbooks highlight confusion in CVE→KB mapping across trackers, making targeted patch verification essential.

Severity metrics published alongside the CVE (CVSS 3.1 = 7.8) reflect a high potential impact, even though the attack requires local access and some operational preconditions (e.g., triggering a restart). That said, the preconditions (low‑privileged local access and the ability to trigger a reboot) are common in many threat scenarios, including web shells on servers, phishing‑gained local sessions and misconfigured remote management. (cvefeed.io)

---

What’s been fixed and how Microsoft responded​

• Research labs report that Microsoft issued an Arc agent update which addresses the named‑pipe/IPC hardening and other integrity checks. Cymulate notes Midated ARC Agent services version 1.61 on March 10, 2026 as a mitigation for CVE‑2026‑26117. (cymulate.com)
• ReverseC’s technical advisory documents the specific remediation implemented: the agent now verifies the owner of the HIMDS named pipe before interacting with it, and stops interacting if the owner is not the expected service account or a local administrator. This removes the implicit trust that allowed a malicious pre‑bound listener to masquerade as HIMDS. (labs.reversec.com)
• Microsoft’s Security Update Guide entry for CVE‑2026‑26117 exists as the authoritative tracking record; however, vendor entries for Arc‑related CVEs are sometimes concise and lack PoC details, so defenders must cross‑check agent release notes and independent advisories to map fixed builds to agent packages in their environment. (cvefeed.io)

---

Verifying whether you are affected​

• Check agent version: identify Arc‑joined machines reporting an agentVersion older than the patched release (Cymulate indicated fixes are in agent services >= 1.61). Use your inventory tooling, Azure Resource Graph or the Azure portal’s Arc resource details to collect agentVersion values across hosts. (cymulate.com)
• Confirm build mappings: because agent packages are distributed across OS families and installers, validate the CVE→KB/package mapping in your environment before automating remediation. Community threads and advisories have warned of identifier fragmentation — do not rely on a single tracker. (cvefeed.io)
• Check scheduled tasks and update scripts: ReverseC’s PoC exploited azcmagent’s scheduled update flow and an msiexec repair path. Audit scheduled azcmagent tasks and the agent’s update script behaviour on Windows hosts to verify they obey integrity checks. (labs.reversec.com)

---

Immediate mitigations and recommended patching steps​

Apply the following steps immediately across Arc‑managed estates. These are practical, sequential actions defenders can take today.

• Prioritize patching:
• Identify Arc‑enabled Windows machines with agentVersion < 1.61 (or the vendor‑specified fixed version). (cymulate.com)
• Schedule and push the Arc agent update to those machines. Prefer a staged rollout that validates success on representative hosts before broad automation. (cvefeed.io)
• Restart services: most fixes require restarting the Arc agent services (or a full host reboot) to ensure the repaired startup validation is in effect. (cymulate.com)
• Harden local access:
• Lock down local accounts and restrict interactive logons to trusted administrators only.
• Remove unnecessary local admin privileges and deny access to maintenance scheduled tasks where possible.
• Monitor for suspicious agent activity:
• Audit msiexec repair invocations, azcmagent scheduled task executions and unexpected agent‑initiated downloads.
• Hunt for unexpected machine object modifications in Azure (unusual changes to tags, RBAC bindings, or tenant associations). (labs.reversec.com)
• If you can’t immediately patch, mitigate:
• Limit which users can trigger scheduled updates and reboot the system.
• Where practical, configure host‑level firewall rules or AppLocker/WDAC policies to restrict who can bind to agent IPC endpoints (named pipes or local HTTP ports). Note: careful testing is required to avoid breaking legitimate agent functionality.

---

Detection and hunting playbook (practical checks)​

Use the following prioritized detection rules and hunting steps to find signs of exploitation or preconditions that could be abused.

• Inventory and query agentVersion across Arc resources; flag any machine with versions older than the fixed version for urgent patching. (Search via Azure Resource Graph or inventory tooling.) (cymulate.com)
• Look for recent device restarts followed by azcmagent or himds start‑up sequences that show abnormal named‑pipe ownership or binding failures in Windows Event Logs (System and Application). ReverseC’s PoC uses a restart to exploit delayed startup. (labs.reversec.com)
• Alert on msiexec repair or unexpected MSI install activity initiated by system user accounts within narrow time windows arountasks. ReverseC shows a malicious MSI execution as a practical result of the chained exploit. (labs.reversec.com)
• Hunt in Azure for recent changes to Arc machine objects: RBAC changes, unexpected tag modifications, or a machine that appears to be re‑registered to a different tenant. Such cloud‑side signals are high‑value telemetries for exploitation of the machine’s cloud identity. (cymulate.com)

Numbered checklist for incident responders:

• Identify unpatched Arc‑enabled machines (agentVersion < fixed). (cymulate.com)
• Isolate suspect hosts from management networks where possible.
• Collect EDR/process snapshots for msiexec, azcmagent, himds.exe and any binary that bound named pipes at the suspected time of compromise. (labs.reversec.com)
• Rotate any machine‑level credentials or service principals that may have been exposed or misused.
• Review Azure Activity Logs and Resource Graph for unexpected machine object changes. (cymulate.com)

---

Strengths in Microsoft’s response and public analysis​

• Microsoft documented the CVE and made a fixed agent release available rapidly; vendor tracking in the Security Update Guide provides the authoritative record. (cvefeed.io)
• Independent researchers published detailed analysis and PoC patterns quickly, giving defenders actionable telemetry to hunt and validate remediations (notably Cymulate and ReverseC). Those write‑ups also describe the cloud‑identity consequences, which are essential for prioritization. (cymulate.com)
• The patch implements explicit named‑pipe owner validation and additional integrity checks — a precise fix to the core trust assumption that was exploited, rather than an ad‑hoc mitigation. (labs.reversec.com)

---

Risks, unknowns and caveats​

• Public exploitation status: as of March 10, 2026 there is no widely published evidence of large‑scale, active exploitation in the wild, but the local‑access preconditions mean attackers with footholds (webshells, RDP compromise, or local account compromise) could weaponize the flaw rapidly once unpatched victims are identified. Monitor carefully for any new reported exploitation. (cymulate.com)
• CVE / advisory fragmentation: multiple overlapping CVE identifiers and vendor entries for Arc agent issues in recent months have created confusion in mapping CVEs to specific KBs and builds; administrators must validate the exact package and agentVersion in their environment rather than assuming a tracker label is sufficient. Community threads reflect this mapping problem.
• Edge cases and environment variance: not all deployment models are identical. Arc agents installed via Group Policy, MSI repair flows, or custom installers can result in different update behaviors. The specific exploit path in a single organization may therefore vary, and some remnants of older fixes may leave hosts vulnerable until fully reconciled. ReverseC’s advisory documents a particular scheduled‑task/MSI pathway that may not be universal. (labs.reversec.com)

Cautionary note: some early public trackers may list incomplete affected‑product tables or speculative vectors; treat vendor advisories and detailed technical write‑ups as primary, and flag any unverified claims. (cvefeed.io)

---

Operational recommendations (for security teams and sysadmins)​

• Patch fast, but verify: identify Arc agent versions across your estate and prioritize update to the fixed agent services release (>= 1.ing). Validate the update in a small pilot first, confirm that agentVersion updates, and only then automate across production. (cymulate.com)
• Apply least privilege to local users: remove unnecessary local admin rights and ensure scheduled tasks that touch agent updates cannot be triggered by non‑privileged users.
• Strengthen boot/startup integrity: minimize opportunities for attacker pre‑binding by reducing the time window where services run in delayed start mode and by enforcing strong AppLocker/WDAC policies for components that bind IPC endpoints. Test any startup policy changes thoroughly.
• Improve detection: deploy the hunting checklist above across EDR and SIEM, and raise high‑priority alerts for msiexec repair + azcmagent orchestration patterns around reboots. (labs.reversec.com)
• Audit cloud‑side changes: review Azunexpected changes to machine objects, RBAC assignments, or tenant affiliations — these are strong indicators of agent identity abuse. (cymulate.com)

---

For incident responders: containment and recovery​

• If you detect possible exploitation, isolate the host from management networks and revoke any tokens or service principals tied to the machine object.
• Capture forensic artifacts: the contents of Windows Event Logs, azcmagent logs, named‑pipe ownership snapshots and msiexec invocation logs. These will be vital to reconstruct the chain. (labs.reversec.com)
• Rebuild vs. remediate: given the potential for SYSTEM compromise and cloud identity abuse, treat affected hosts as high‑confidence compromises; plan for rebuilds from known good images after eradicating persistence and rotating credentials.
• Assess cloud impact: check which RBAC roles the machine used and whether any changes to cloud resources were made; look for lateral activity that used machine‑level privileges. (cymulate.com)

---

Broader lessons and closing analysis​

CVE‑2026‑26117 is a textbook example of how local IPC trust assumptions and service‑startup ordering can turn a local privilege control bug into a full‑blown hybrid cloud compromise. The vulnerability highlights three enduring security lessons:

• Trust boundaries matter: endpoints that bridge on‑premises hosts to cloud control planes must assume minimal trust from local actors and must design strong, cryptographic mutual authentication even for “local” service interactions. (cymulate.com)
• Patch mapping and observability are critical: modern distributed management agents require robust inventory and version telemetry. Having agentVersion telemetry surfaced in central telemetry systems (Azure Resource Graph, configuration management, or asset inventory) allowed researchers and defenders to map exposure quickly. (cymulate.com)
• Multi‑layer detection reduces risk: endpoint controls, startup integrity policies, scheduled‑task hardening, AppLocker/WDAC, and cloud telemetry together reduce the windows of opportunity an attacker needs to exploit a bug chain like this.

This advisory should be treated as an urgent patch‑and‑hunt item by any organization that uses Azure Arc to manage Windows servers. The fix addresses the core trust failure, but the operational work — agent inventory, staged rollouts, detection exercises and cloud object audits — is where most organizations will need to spend their attention and resources. Community threads and vendor advisories underscore that correct CVE→KB mapping and verification of agentVersion across heterogenous deployments are essential steps in preventing residual exposure. (cymulate.com)

---

Action checklist (executive summary)​

• Immediately: identify Arc‑enabled Windows machines with agentVersion older than the fixed release and schedule a prioritized patch. (cymulate.com)
• Within 24–48 hours: apply the Arc agent update on pilot hosts, confirm agentVersion changes and restart services. (cymulate.com)
• Within 72 hours: roll out agent update broadly with verification steps, hunt for indicators described above, and audit cloud machine object changes. (labs.reversec.com)
• Ongoing: enforce least privilege locally, collect named‑pipe and startup integrity telemetry, and monitor for msiexec/installer anomalies near azcmagent scheduled tasks. (labs.reversec.com)

---

CVE‑2026‑26117 demonstrates the dangerous interplay between local privilege mechanics and cloud identity authority; patching the agent is necessary but not sufficient — organizations must combine rapid remediation with focused detection and cloud audit controls to fully close the attack path. (cvefeed.io)

---

Source: MSRC Security Update Guide - Microsoft Security Response Center