SharedRoot Flaw Let One Message Escape Claude's Sandbox

"We connected a folder to a fresh Claude Cowork session, sent one short message, and watched the agent escape the sandbox." That's how researchers at Accomplish AI describe triggering the flaw. No prompt injection, no malware, no second stage. Just a chat message and an agent that did exactly what an attacker inside that sandbox would want it to do.

That's the disclosure the Israeli security firm published on July 23, describing a vulnerability it calls SharedRoot in Claude Cowork, Anthropic's desktop agent that runs Claude inside an isolated Linux VM so it can touch a user's local files without touching the rest of the machine. The isolation didn't hold. Principal researcher Oren Yomtov and Accomplish AI co-founder and CTO Or Hiltch say the escape path exposed roughly 500,000 macOS users running local Cowork sessions to full read-write access on their host filesystem, including SSH keys and cloud credentials.

TL;DR

Accomplish AI disclosed SharedRoot, a sandbox escape in Anthropic's Claude Cowork desktop agent, on July 23
One chat message let an agent break out of Cowork's Linux VM and reach the full host Mac filesystem
The chain leans on CVE-2026-46331, a Linux kernel bug in the act_pedit traffic-control module disclosed in June
Accomplish AI estimates roughly 500,000 macOS users running local sessions were exposed
Anthropic closed the researchers' report as "Informative" and did not ship a direct fix

How One Message Broke Out of the VM

Cowork's sandbox model is straightforward on paper: the agent runs inside a Linux VM, that VM gets read-write access to whatever folder the user connects, and everything else on the Mac stays out of reach. SharedRoot shows the "everything else" part was never actually walled off.

The chain starts with a Linux primitive that's available to any unprivileged process. From there it climbs to root inside the VM, then out of it completely:

# 1. Enter an unprivileged user namespace - becomes "root" inside it
unshare --user --map-root-user --net

# 2. That namespace grants CAP_NET_ADMIN, enough to configure traffic control
tc qdisc add dev lo root handle 1: prio
tc filter add dev lo parent 1: protocol ip u32 match u32 0 0 \
   action pedit munge offset 0 u8 set 0

# 3. Loading act_pedit here triggers CVE-2026-46331, corrupting the
#    page cache of a root-owned helper binary before it's re-executed

# 4. Cowork's root daemon (coworkd) re-runs the poisoned binary,
#    handing the session guest-root privileges inside the VM

# 5. Guest-root can read the entire host filesystem, mounted
#    read-write via VirtioFS at a hidden path
ls /mnt/.virtiofs-root/Users/<host-user>/

That last mount point is the part Accomplish AI keeps returning to. Cowork wires the whole host / into the VM through VirtioFS specifically so that guest-root, and only guest-root, can see it. Once an agent reaches guest-root through the kernel bug, that boundary stops meaning anything.

Four Design Choices That Added Up to Full Escape

No single decision in Cowork's architecture is unusual on its own. Stacked together, researchers say, they turned a public kernel bug into a full sandbox bypass.

The whole-host mount - Cowork mounts the entire host filesystem into the VM through VirtioFS as writable, rather than scoping the mount to the one folder a user actually connected.

Unprivileged namespaces - Any session user can call unshare and get root-equivalent capabilities, including CAP_NET_ADMIN, inside a new namespace, without needing genuine host privileges first.

A permissive seccomp filter - The sandbox's syscall filter allows netlink socket access, which is exactly what's needed to trigger the vulnerable act_pedit kernel module in the first place.

A daemon that trusts its own binaries - coworkd re-executes a helper binary after the kernel bug has already corrupted it, converting a page-cache bug into a privilege escalation inside the guest.

Accomplish AI says it verified the escape end to end: files written from inside the "isolated" VM appeared in the host user's home directory almost immediately, with no confirmation dialog and no indication to the user that the boundary had been crossed.

Claude Cowork's mobile and desktop interface showing task queues and approvals Cowork organizes an agent's work into a task queue with approval prompts - prompts that never fire for the filesystem escape described in SharedRoot. Source: techcrunch.com

Anthropic's Response

Anthropic's security team closed Accomplish AI's report with a single label: "Informative." According to the researchers, the company's reasoning was that the underlying kernel bug, CVE-2026-46331, was already inside its own 30-day public-disclosure window, making it someone else's problem to patch rather than a flaw in Cowork's sandbox design. Anthropic framed Accomplish AI's four hardening recommendations as defense-in-depth measures rather than fixes for standalone vulnerabilities.

Separately, and without directly addressing SharedRoot, Anthropic shipped a Cowork update that now defaults new sessions to cloud execution instead of the local VM. Cloud execution sidesteps this specific escape path because there's no local host filesystem sitting one hop away from guest-root. Users who keep running Cowork locally, which remains an option, are still exposed.

What Cowork Users Should Do Right Now

Accomplish AI's writeup lists four mitigations for anyone still running Cowork sessions locally on macOS:

Disable unprivileged user namespaces at the sysctl level, closing off the unshare path completely for processes that don't need it.
Apply a default-deny seccomp filter that blocks unshare, setns, clone3, and AF_NETLINK unless a process explicitly needs them.
Block autoloading of unused kernel modules, including act_pedit, so a namespace trick can't pull in a vulnerable module on demand.
Scope the VM's host mount to the connected folder only, and make it read-only wherever the workflow allows, instead of exposing the entire filesystem.

A padlock and keys resting on a Mac keyboard The mitigations Accomplish AI recommends are host-level sysctl and kernel settings, not anything a Cowork user can toggle inside the app. Source: unsplash.com

None of these are things an individual Cowork user can configure from the app itself. They're host-level hardening steps, which is the researchers' underlying point: the sandbox that was supposed to make that hardening unnecessary didn't hold up. Anthropic's shift to cloud-default execution addresses new sessions from now on, but it's a product default, not a patch, and it leaves the local path standing for anyone who opts back into it. Cowork's approval prompts, built for tasks the agent flags as needing permission, never triggered for any step in this chain, because from inside the sandbox none of it looked like it needed one.

Sources: