SharedRoot — Cowork's Sandbox Escape Is an Architecture Problem

Accomplish AI’s Oren Yomtov dropped SharedRoot on July 23 — a complete proof-of-concept that breaks out of Claude Cowork’s Linux VM, traverses to the host Mac filesystem, and reads or writes files anywhere on the machine. No permission prompt. No elevated privileges needed at session start. An unprivileged user inside the guest VM achieves root, then walks straight onto your Mac through a read-write mount that was never supposed to be there. Anthropic has already shifted Cowork sessions to cloud execution by default, but the roughly 500,000 macOS users who ran local sessions — or still opt into them — had their entire host filesystem exposed to whatever the agent decided to do.

TL;DR

• What: Full sandbox escape from Claude Cowork’s Linux VM to the host Mac filesystem, demonstrated with a working PoC
• How: CVE-2026-46331 (pedit COW) escalates to guest root; VirtioFS mount at /mnt/.virtiofs-root gives read-write access to the entire host
• Real problem: The kernel bug is the vehicle — the architecture (whole-host mount, root daemon, permissive seccomp) is the cause
• Action: If you run any AI agent locally with VM isolation, audit your mount scope, daemon privileges, and seccomp profile today

SharedRoot — What Happened

The exploit chain has four links, and only one of them is a bug. The other three are design choices.

Link 1: Permissive seccomp. Cowork’s guest VM allows unprivileged user namespaces. This is a kernel feature that can be disabled with a single sysctl flag. Anthropic left it on. No exploit needed — just a configuration that was never locked down.

Link 2: CVE-2026-46331 (pedit COW). A Linux kernel privilege-escalation vulnerability in the traffic control subsystem, publicly disclosed by researcher Massimiliano Oldani on June 17, 2026 with a working proof-of-concept. A local unprivileged user poisons the page cache of a setuid binary (typically /bin/su), gaining root inside the guest. This is the only actual bug in the chain.

Link 3: coworkd runs as root. The daemon that shares user-connected folders into the VM operates with root privileges, unhardened. Once you have guest root, you inherit the same inode view coworkd has.

Link 4: Whole-host VirtioFS mount. The entire host filesystem is exposed at /mnt/.virtiofs-root with read-write permissions. Not a scoped project directory. Not a session-specific sandbox. The whole Mac. Your SSH keys, your .env files, your browser profiles, your password manager databases — all accessible the moment guest root is achieved.

# From inside the Cowork VM, after guest-root escalation:
ls /mnt/.virtiofs-root/Users/$(whoami)/.ssh/
# id_rsa  id_rsa.pub  known_hosts  config

The pedit COW kernel bug will get patched. Linux kernel CVEs come and go. But the architecture that makes this chain lethal — the unscoped mount, the root daemon, the permissive namespace policy — those survive the patch. The next privilege-escalation CVE with the same shape reopens the same door.

Why This Matters

This is the second time in four months that researchers have demonstrated a full sandbox escape against Claude Cowork’s VM isolation. The first was Armadin’s chain, reported to Anthropic on March 20, targeting the Windows/Hyper-V variant against Claude Desktop for Windows v1.9255.2.0. Anthropic responded on March 24 that it did not qualify as a security vulnerability because exploitation requires an attacker to already have local code execution on the host machine.

That response reveals a threat model disconnected from how AI agents actually work. Claude Cowork processes untrusted content by design. It clones repos, fetches URLs, reads user-supplied files, executes code. Prompt injection through a malicious repository or a compromised dependency is not an edge case — it is the primary attack surface. When Anthropic says “local code execution is a prerequisite,” they are describing the agent’s normal operating mode.

The architectural mistakes are worth naming individually because they are not unique to Anthropic. Any team shipping a local AI agent with VM isolation should check their own setup against this list.

Unscoped filesystem mounts. If your VM can see the host’s / instead of a session-specific working directory, you have built a containment boundary and then removed it. VirtioFS, 9p, shared folders — the transport does not matter. The scope does.

Root daemons without hardening. Running the agent’s host-side daemon as root means every guest-to-host traversal inherits maximum privileges. Drop to a dedicated service user. Apply capability restrictions. This is baseline Linux hardening from 2010.

Permissive seccomp profiles. Allowing unprivileged user namespaces inside the guest hands attackers the first step of most modern kernel exploits for free. The Accomplish AI writeup is explicit: there is no exploit in this step at all — it is a kernel feature that could have been turned off.

If you run any local AI agent with VM isolation — not just Cowork — verify three things now: (1) host filesystem mounts are scoped to session-specific directories, (2) the agent daemon does not run as root, (3) your seccomp profile blocks unprivileged user namespace creation.

Compare this to how mature container runtimes handle isolation. Docker’s default seccomp profile blocks over 300 syscalls. gVisor intercepts all syscalls in userspace. Firecracker provides a minimal device model with no host filesystem access by default. These are not exotic configurations — they are table stakes for running untrusted workloads. Cowork’s local VM isolation is closer to a development convenience than a security boundary.

Anthropic’s mitigation — defaulting Cowork sessions to cloud execution — removes the local VM escape path for new users. But it does not change the underlying VirtioFS architecture for users who opt into local execution, and it does not address the design philosophy that produced these choices in the first place.

The Take

The kernel bug is not the story. CVE-2026-46331 will be patched, the page cache poisoning technique will stop working, and Anthropic will update their VM image. None of that fixes the problem.

The problem is that Anthropic mounted the entire host filesystem into the agent’s VM read-write and ran coworkd as root without hardening. Those are design decisions, not accidents, and they will welcome the next privilege-escalation CVE with open arms. Every few months, a new Linux kernel escalation surfaces — it is one of the most reliable patterns in security. The architecture needs to survive those disclosures, not just the current one.

When a vendor dismisses a full host-filesystem escape chain because it “requires local code execution,” they are telling you their threat model does not include your SSH keys. For a text editor, that prerequisite is meaningful — an attacker needs a separate entry point. For an AI agent that clones repositories, processes URLs, and executes arbitrary code as its core function, local code execution is not a prerequisite. It is a feature.

I would not run Claude Cowork in local mode on any machine with secrets I care about until Anthropic scopes the VirtioFS mount to session directories and drops coworkd off root. Cloud execution is the right default, but it is a routing decision, not an architectural fix. The question is whether Anthropic treats this as a containment design problem or continues treating each individual CVE as a one-off. Two independent escape chains in four months suggests the former is overdue.

Related

• Claude Code RCE via Config Files — a different attack surface on Claude’s local tooling, same pattern of trusting the local environment too much
• Claude Cowork Mobile Usage Data — context on Cowork’s expanding user base beyond developers
• The Post-Mythos Security Stack — hardening patterns for AI agent deployments