Claude Cowork Flaw Could Let AI Agent Escape Its VM and Access Mac Files

Summary

Researchers at Accomplish AI disclosed a sandbox-escape vulnerability, codenamed SharedRoot, in Anthropic's Claude Cowork. When a folder is connected to a fresh local Cowork session, the AI agent can break out of the Linux VM in which it runs and read or write files anywhere on the host Mac, far beyond the connected folder and without any permission prompt.^[1]

The exploit chains user/network-namespace creation to obtain CAP_NET_ADMIN, loads the kernel's act_pedit Traffic Control subsystem, and triggers CVE-2026-46331 (pedit COW) in the guest kernel to gain guest-root. Because the entire host filesystem is mounted read-write into the VM at /mnt/.virtiofs-root, guest-root translates directly into full host access, exposing data such as SSH keys and cloud credentials as the logged-in desktop user.^[1]

Accomplish AI stated roughly 500,000 macOS users running local Cowork sessions were affected before the issue was addressed. Anthropic closed the report as informative without a dedicated fix; the latest Cowork release defaults to cloud execution which mitigates the issue, but users who opt to run the agent locally remain exposed.^[1]

Attack chain

1. Initial trigger: A user connects a folder to a fresh Claude Cowork session and sends a single short message, after which the agent begins the escape from inside its Linux VM.^[1]
2. Privilege prerequisite setup: The agent creates user and network namespaces, granting the session CAP_NET_ADMIN within its private network namespace and making the normally-privileged tc/act_pedit kernel path reachable by an ordinary user.^[1]
3. Kernel exploitation: The agent loads the Linux kernel's act_pedit Traffic Control packet-editing subsystem into the unprivileged user namespace and exploits CVE-2026-46331 (pedit COW), a memory bug, in the guest kernel to obtain guest-root.^[1]
4. Sandbox escape / host access: With guest-root, the agent accesses the entire host filesystem mounted read-write at /mnt/.virtiofs-root, reading and writing files anywhere on the Mac as the logged-in desktop user, including SSH keys and cloud credentials.^[1]

Disclosure timeline

How it works

Claude Cowork's macOS desktop app runs as the logged-in user, but agent work happens inside a Linux VM created via Apple's Virtualization framework. Each session gets a disposable unprivileged user and a seccomp filter for sandboxing, and connected folders are shared into the VM by a root daemon called coworkd.^[1]

The critical design flaw is that the entire host filesystem ('/') is mounted read-write into the VM at /mnt/.virtiofs-root, visible only to guest-root inside the VM. Any path to guest-root therefore grants access to the underlying host, effectively escaping the sandbox.^[1]

The escape works by creating user and network namespaces to obtain CAP_NET_ADMIN, loading the kernel's act_pedit Traffic Control subsystem, and exploiting CVE-2026-46331 (pedit COW), a memory bug in the net/sched subsystem, to escalate to guest-root. The namespaces are not the exploit themselves; they make the normally privileged prerequisite available to an ordinary user.^[1][23]

The researchers characterize act_pedit as one instance of a recurring class of Linux net/sched privilege-escalation bugs: an autoloadable module, a config path an unprivileged user can reach, and a memory bug at the end, meaning patching one bug does not close the structural exposure.^[1]

Affected versions and patch status

Key takeaways

• AI agents that run local code in a VM inherit the VM's kernel attack surface; a single message to a Cowork session was enough to chain namespace abuse and a kernel CoW bug into full host file access with no permission prompt.^[1]
• Mounting the entire host filesystem read-write into an agent VM converts any guest-root primitive into a complete host compromise, so scope and mount posture matter as much as the kernel patch level.^[1]
• The researchers argue this is a structural, not a patch-cadence, problem: the Linux net/sched subsystem repeatedly produces the same class of privilege-escalation bug, so defenders remain 'one bug behind' unless they remove the prerequisites (unprivileged namespaces, module autoloading, permissive seccomp, full-host mounts).^[1]
• Vendor triage disagreement is notable: Anthropic closed the disclosure as informative without a dedicated fix, relying on the cloud-execution default, leaving locally-run agents exposed.^[1]

Defensive actions

• Use cloud execution mode for Claude Cowork rather than running the agent locally.: The latest Cowork version defaults to cloud execution, which addresses the sandbox escape; local execution remains exposed to the SharedRoot chain.^[1]
• Disable unprivileged user namespaces on the host/guest configuration.: User and network namespace creation is what grants the session the CAP_NET_ADMIN capability needed to reach the vulnerable tc/act_pedit kernel path.^[1]
• Avoid overly permissive seccomp filters and stop autoloading of kernel modules.: An overly permissive filter and module autoloading allow the unprivileged session to reach and load the vulnerable act_pedit subsystem.^[1]
• Restrict host filesystem sharing into the VM by scoping mounts to only the connected folders or mounting read-only.: Mounting the entire host '/' read-write into the VM is what turns guest-root into full host access; scoping or read-only mounts leave a guest-root escape with nothing to land on.^[1]
• Run coworkd with ProtectSystem=strict in its own mount namespace.: This prevents the root daemon from re-execing binaries that a session user could poison, removing the final steps of the exploit chain.^[1]