Claude Cowork sandbox: a disputed root escape and the local-code-execution debate

What is this?

On 1 July 2026 the security firm Armadin published an attack chain that reaches a root shell inside the isolated Linux sandbox that Anthropic’s Claude Cowork uses to run untrusted code, and a second step that removes the network egress restrictions meant to contain that sandbox. The write-up was covered the same day by SiliconANGLE, SC Media, GBHackers and others. The important nuance is in the framing: Armadin reported the chain to Anthropic earlier in 2026, and Anthropic declined to treat it as a security issue because pulling it off requires the attacker to already have local code execution on the host machine. No CVE was assigned. So this is not a remotely exploitable zero-day — it is a disclosed weakness in a defense layer, and a genuine disagreement about how much a sandbox is supposed to protect against an attacker who is already on the box.

How it works

The chain, as described publicly, has two conceptual parts. The first is a classic DLL sideloading foothold (MITRE ATT&CK T1574.002): the signed Claude desktop binary resolves a system library from its own application directory before falling back to the real system copy, so a file planted alongside it with the expected name and exported function runs inside a legitimately signed process. That step requires the attacker to already be able to write files and run code on the host — the precondition Anthropic points to.

The second part is the more interesting one for agent builders. The sandbox is provisioned by a local privileged service that the desktop app talks to over an inter-process channel. One of the parameters that controls how a session is set up was trusted without validation: a flag that is supposed to force creation of a fresh, unprivileged user could instead be flipped to reuse an arbitrary named account, and the service honored a request naming the superuser without checking it. The result was a root shell inside the container rather than the constrained user the design intended. A related gap let the caller drop the egress filtering that was supposed to keep the sandbox from talking to arbitrary hosts. We are deliberately describing the shape of the flaw rather than reproducing the parameters, because the useful lesson is architectural, not a recipe.

Why it matters

The disagreement is the story. Anthropic’s position — that a sandbox escape gated behind pre-existing local code execution is not a vulnerability — is a defensible and common one: if the attacker already runs code as you, they can already read your files and keys, so the sandbox was never your last line of defense. Armadin’s implied counterpoint is the defense-in-depth argument: Cowork’s whole value proposition is running untrusted content, and a containment layer that goes from unprivileged to root and from network-restricted to unrestricted through a single unvalidated flag is a weaker boundary than the design implies. Both can be true at once. What matters for anyone shipping an agent that runs code is that the privileged helper provisioning your sandbox is itself part of the attack surface, and that trusting parameters from a less-privileged caller re-creates a decades-old confused-deputy pattern inside a brand-new AI runtime. The signed-binary sideloading angle also matters: attackers value execution inside a trusted, signed process for evasion, and AI desktop apps are now high-value hosts because they hold API keys, cloud credentials, and access to whatever the agent is wired into.

Defenses

For teams building or operating agent sandboxes, treat the local provisioning service as a security boundary and validate every parameter it receives from the app, especially anything that selects a user, privilege level, or network policy; a flag that requests root should be rejected outright, not honored. Assume the sandbox will occasionally be escaped and add layers that survive that: least-privilege host accounts, egress filtering enforced outside the container the caller can influence, and monitoring for a sandbox process that suddenly runs as root or reaches an unexpected host. Harden against DLL sideloading by resolving system libraries from fixed system paths, enabling safe library-search order, and signing-plus-integrity-checking the application directory so a planted file next to a signed binary is detected. For end users, the practical takeaway is unchanged: keep host machines that run agent desktop apps patched and free of untrusted code, because on this class of issue the host is the trust anchor. If you operate Claude Cowork in an enterprise, apply endpoint controls that detect local code execution and unauthorized writes into application directories, since that is the precondition the whole chain depends on.

Status

Publicly disclosed by Armadin on 1 July 2026 after private reporting to Anthropic earlier in the year. Anthropic responded that it does not consider the chain a security issue because exploitation requires pre-existing local code execution on the host; no CVE was assigned and no patch was announced.

Item	Detail
Disclosed	Armadin write-up, 1 July 2026
Product	Claude Cowork sandbox (Linux VM on Windows host)
Foothold	DLL sideloading into a signed desktop binary (T1574.002)
Escalation	Unvalidated session-provisioning parameter → root in sandbox; egress filtering bypass
Precondition	Attacker already has local code execution on the host
Vendor status	Not treated as a security issue; no CVE, no patch announced