Cowork sandbox escape: a signed RPC that trusted client privilege flags

What is this?

On 2–3 July 2026, security outlets published a research write-up from Nick McClendon of Armadin describing a full escape of the Linux sandbox that ships inside Claude Cowork, Anthropic’s desktop product for non-developers. The chain lets an attacker who already has code execution on the host reach a root shell inside the agent’s sandbox, disable its network egress controls, and break out into the host VM’s namespaces. According to the same reporting, the finding was disclosed to Anthropic on 20 March 2026 and validated against Claude Desktop for Windows build 1.9255.2.0. This is a design-lesson write-up, not an actionable exploit.

The interesting part is not that a sandbox broke — sandboxes break — but how. The control channel that manages the sandbox authenticated who was calling while trusting what they asked for. That single confusion between identity and authorization is the reusable lesson for anyone building an AI agent runtime.

How it works

On Windows, Cowork runs Claude Code inside a Hyper-V-isolated Ubuntu VM provisioned through the Host Compute Service. The isolation is layered: a Local System service (CoworkVMService) exposes a JSON-RPC server over a named pipe, and it only accepts callers whose binary carries a valid Authenticode signature from “Anthropic, PBC”. Inside the VM, work runs under a bubblewrap namespace as a per-session unprivileged user, behind a seccomp filter and a domain-restricted egress proxy.

The researchers first tried to forge the signature and failed — WinVerifyTrust held. So instead of breaking the identity check, they satisfied it. Because the signed claude.exe resolved a system library from its own application directory before the system path, a look-alike library placed alongside it ran attacker code inside the trusted, signed process — a classic DLL search-order hijack (MITRE ATT&CK T1574.002). From there the caller inherited Anthropic’s signing trust and could talk to the pipe legitimately.

The escalation came from the RPC contract itself. Service logs on disk revealed the method schema, including a spawn call with client-supplied parameters. Two of them were trusted verbatim by the guest daemon. A resume-session flag, intended to reattach to an existing session, skipped the code path that creates a fresh unprivileged user — so a request naming an arbitrary existing user (including the superuser) simply ran as that user, with full capabilities and an unconfined profile. A domains parameter set to a wildcard turned the restrictive egress proxy into an open one. With a root process inside the namespace, standard nsenter against PID 1 then stepped out into the host VM’s mount, PID and network namespaces, exposing files like /etc/shadow. No payload is reproduced here; the mechanism is the point.

Why it matters

Every protective layer functioned as designed, and the box still opened, because a privileged server delegated security decisions — which user to run as, which domains to reach — to values the client controlled. Signature-gating a control channel proves the caller’s identity; it says nothing about whether a given request should be authorized. This is the same trust-boundary problem behind agent harness privilege boundaries and environment-based leaks in coding agents, and it is exactly why zero-trust framing for agents treats the sandbox as one control among many rather than the control.

Anthropic’s position, per the reporting, is that this is not a security vulnerability because it presupposes local code execution on the host, which is outside its threat model. That is a defensible line for traditional software — but it deserves scrutiny for AI agent tools specifically, because those tools exist to execute untrusted code and follow untrusted instructions. “Requires local execution” is a weaker boundary when running attacker-influenced content is the product’s core function.

Defenses

For builders, the durable rule is that authentication is not authorization: a signed or allow-listed caller must still have every method and parameter checked server-side, and privilege or egress decisions must never be taken from client-supplied fields. Resume/reattach paths should re-derive identity from server state, not from a caller-provided name. Harden the identity check’s foundation too — a signature gate is only as strong as the signed process’s code integrity, so enforce a safe DLL search order and packaged-app integrity so a trusted binary cannot be made to load an untrusted library.

For operators, treat any environment that runs AI-generated code as untrusted, and layer controls beyond the sandbox: restrict which signed apps can launch (for example with AppLocker packaged-app rules), monitor for anomalous library loads such as a system DLL loading from outside System32 (Sysmon Event ID 7), keep agent runtimes off production networks and away from secrets stores, and alert on unexpected privilege changes or egress from agent sandboxes. Assume sandbox escapes will be found and plan the blast radius accordingly.

Status

Item	Detail
Disclosure	Nick McClendon (Armadin); reported to Anthropic 20 March 2026; public write-ups 2–3 July 2026
Nature	Sandbox privilege escalation and escape via DLL search-order hijack + control-plane RPC that trusts client privilege/egress flags
Validated on	Claude Desktop for Windows build 1.9255.2.0
Precondition	Local code execution on the host
Vendor position	Classified by Anthropic as not a security vulnerability (local execution treated as a prerequisite); no CVE assigned at time of writing
Class	Authentication ≠ authorization; broken access control in an agent control plane

Details reflect third-party reporting of the Armadin research as tested on a specific Windows build. Vendor positions and product internals change over time — verify against the current version of any deployment before drawing conclusions.