Claude Cowork Sandbox Flaw Lets Local Attackers Run Commands as Root Inside Windows VM

Security researchers say a vulnerability chain in Anthropic’s Claude Cowork for Windows can let an attacker with local code execution run commands as root inside the product’s isolated Linux sandbox. The finding matters because Cowork relies on that sandbox to contain agent activity while Claude Code runs tasks for users.

The attack does not appear to be a remote compromise by itself. The attacker first needs local code execution on the Windows host. From there, the reported chain abuses a signed Anthropic process, a Windows service interface, and weak parameter validation to reach root inside the Cowork virtual machine.

Armadin published the research on July 1, 2026, describing a path from local execution to root commands inside the sandbox. A separate SiliconANGLE report said Anthropic did not classify the issue as a security vulnerability because the chain depends on an attacker already having code execution on the host machine.

What Claude Cowork Was Designed to Contain

Claude Cowork is Anthropic’s agent product for knowledge work. On Windows, the product uses a Linux environment to run Claude Code tasks with several containment layers between the user’s desktop and the agent’s execution environment.

Anthropic’s own containment overview describes agent security as a mix of environment restrictions, model-layer controls, and runtime defenses. The company says containment matters because agents can interact with files, tools, network resources, and user data.

The related Claude Code sandboxing documentation says the sandboxed Bash tool provides filesystem and network isolation, with operating-system enforcement for commands and child processes. On Linux and WSL2, it relies on bubblewrap and network relay components to restrict what commands can reach.

Reported Attack Chain at a Glance

Stage	What researchers reported	Why it matters
Local foothold	The attacker already has code execution on the Windows host.	This limits the issue, but still matters for sandbox trust boundaries.
Signed process abuse	The attacker gets code running inside an Anthropic-signed executable.	The process passes the identity checks used by the Cowork service.
DLL sideloading	A malicious DLL is loaded by the signed process.	The attacker gains execution inside a trusted process.
Service access	The trusted process communicates with CoworkVMService.	The service exposes methods used to manage the underlying VM.
Parameter abuse	Unvalidated spawn parameters alter how commands run in the VM.	The attacker can run commands as an existing privileged user.
Root execution	Commands run as root inside the Linux sandbox.	The per-session unprivileged-user boundary no longer holds.

The chain begins with a local Windows execution requirement. That condition explains Anthropic’s reported position, but it does not remove the architectural concern for organizations that treat an agent sandbox as a meaningful boundary after endpoint compromise.

The main risk is not that the bug gives an internet attacker instant access. The risk is that a compromised endpoint may allow an attacker to turn a trusted agent sandbox into a more privileged execution environment with fewer restrictions than expected.

DLL Sideloading Was the First Pivot

Researchers said they could not bypass the service’s Authenticode signature check directly. Instead, they moved code into an Anthropic-signed process and then used that process to communicate with the service.

The technique resembles MITRE ATT&CK DLL sideloading, where attackers place a malicious library where a legitimate application will load it. This lets malicious code run inside a trusted process without modifying the signed executable itself.

Microsoft’s DLL search order documentation explains why this class of bug exists. When an application loads a DLL without a fully qualified path, Windows searches a defined set of locations, and attackers can abuse a writable or controllable location if developers do not harden library loading.

How the Root Execution Path Worked

After gaining code execution inside the signed Anthropic process, the attacker could interact with the CoworkVMService named-pipe interface. That service manages communication with the Linux VM used by Claude Cowork on Windows.

The reported break came from parameters passed to the VM-side daemon. Researchers found that a resume-related flag and domain-list setting were forwarded too broadly, which let them bypass the intended creation of a fresh unprivileged user for each session.

Instead of creating a locked-down user, the daemon could be made to run a command as an existing user inside the VM. In the reported proof of concept, that existing user was root.

Why Network Controls Also Matter

Sandbox escapes become more serious when network restrictions fail at the same time. Armadin said the root execution path also avoided the domain-restricted egress path that normally limits where agent-run commands can connect.

That matters because Anthropic’s containment model frames filesystem boundaries and egress controls as core defenses. If credentials or sensitive files stay outside the sandbox, and network access remains restricted, data theft becomes harder even when agent behavior goes wrong.

The Claude Code sandbox guide also warns that effective sandboxing needs both filesystem and network isolation. If either side gets widened too far, the other restriction may not provide enough protection.

Anthropic Reportedly Disputed the Severity

The key dispute centers on the threat model. According to SiliconANGLE, Anthropic responded that the finding did not qualify because exploitation requires local code execution on the host.

That position is common in security triage when a report depends on a prior compromise. However, agent sandboxes are often sold or understood as containment layers that should limit what code can do after it starts running.

For enterprises, the practical question is whether Cowork’s sandbox should protect only against model behavior and untrusted task execution, or whether it should also hold as a post-compromise boundary on a partially compromised endpoint.

Security Lessons for AI Agent Sandboxes

• Do not treat a signed local process as a complete trust boundary.
• Harden DLL loading with fully qualified paths and safe loading APIs.
• Validate privileged RPC parameters on both the host side and guest side.
• Do not let resume or restore features bypass privilege checks.
• Apply network egress controls to privileged management paths as well as user commands.
• Log agent service calls, VM spawn requests, and unexpected root activity inside guest environments.

The finding also shows why AI agent tools need security review beyond prompt injection. A model may run commands, but the surrounding orchestration layer decides which commands execute, which user runs them, what network path they use, and what files they can access.

This is especially important for products that let non-technical users automate work with code execution. The user may never see the low-level boundary decisions that determine whether a task stays contained.

What Windows Administrators Should Watch

Organizations using Claude Cowork on Windows should review local endpoint hardening. The first stage requires local code execution, so application allowlisting, endpoint detection, and controlled installation paths remain important mitigations.

Admins should also watch for unusual DLL files placed beside signed application binaries, unexpected child processes from Claude Desktop components, and unusual named-pipe communication with CoworkVMService. Monitoring should include both the Windows host and the Linux guest environment.

Microsoft recommends safer DLL loading practices in its dynamic-link library search order guidance. MITRE’s DLL side-loading technique page also gives defenders a useful framework for mapping detection and mitigation work.

Why This Finding Matters Beyond Claude Cowork

The reported bug chain reflects a broader issue in AI agent security. Agent products increasingly combine local apps, cloud identity, developer tools, virtual machines, proxies, and automation layers. A weakness in any part of that stack can weaken the final boundary.

That does not mean all sandboxed AI tools are unsafe. It means buyers and security teams should ask what the sandbox protects against, who the trusted components are, and whether local compromise changes the answer.

Armadin’s research makes one point clear: a sandbox boundary should not depend only on who signed the host binary. It also needs strict input validation, safe library loading, least-privilege service design, and consistent enforcement inside the guest environment.

FAQ