SharedRoot Turned Guest Root Into Host File Access in Claude Cowork
Accomplish security researcher Oren Yomtov has published SharedRoot, an end-to-end escape from the local Linux virtual machine used by Claude Cowork on macOS. The chain elevated an unprivileged agent session to guest root with Linux kernel vulnerability CVE-2026-46331, then used a read-write VirtioFS mount of the Mac’s entire filesystem to access files beyond the folder connected to Cowork.
The disclosure is more important as a boundary-design failure than as another kernel exploit. A patched guest kernel would stop this particular path. It would not answer why guest root—obtained through any future kernel flaw—could see the whole host filesystem read-write. Accomplish says it reproduced both reading and writing outside the granted folder, without an additional permission prompt.
The reported local architecture is no longer Cowork’s default execution path. Accomplish says Anthropic closed the report as “Informative” and that cloud execution now appears not to expose the same route. Anthropic’s current safety documentation independently states that Cowork sessions run in temporary environments on Anthropic’s servers and reach a desktop only through connected folders. That is a material mitigation, not evidence that every local installation or historical session was affected in the same way.
Five trust transitions completed the escape
The session began as an unprivileged user inside a disposable Linux VM. According to Accomplish, unprivileged user namespaces were available, allowing that account to create a namespace in which it held capabilities including CAP_NET_ADMIN. The sandbox’s seccomp policy also allowed the namespace and netlink operations needed to configure Linux traffic control.
Referencing the act_pedit traffic-control action caused the guest kernel to autoload code affected by CVE-2026-46331. NVD describes the underlying flaw as an incorrectly calculated copy-on-write range in tcf_pedit_act(): runtime header offsets could leave part of a write region outside the copied range, enabling page-cache corruption. Upstream stable-kernel patches move the writable-range check into the per-key loop and add offset and overflow safeguards.
Accomplish used that corruption primitive against the cached copy of a root-owned helper visible to the session user. When the root coworkd service later re-executed the helper, the poisoned cached image ran with its existing guest-root authority. The final transition required no second vulnerability: guest root could see /mnt/.virtiofs-root, which the researchers identified as a read-write share of the host Mac’s /.
This sequence is worth preserving precisely. CVE-2026-46331 is a local Linux kernel vulnerability, not a remote Claude CVE. The product-level risk emerged from its composition with reachable kernel functionality, a privileged helper, and an overbroad host share. Treating the disclosure as merely “patch the kernel” misses the trust transitions that converted guest escalation into host compromise.
The host mount determined the blast radius
A VM can still be a useful containment layer when its guest kernel is assumed compromisable. The decisive question is what authority survives after guest root is obtained. In SharedRoot, the answer included the logged-in user’s host filesystem because that filesystem was already present inside the VM and writable.
Sharing only explicitly connected folders would have preserved the user-visible data boundary even after the guest privilege escalation. Making broad shares read-only would have reduced integrity impact but still left confidentiality at risk. Keeping enforcement in a host-side broker that exports individual approved paths avoids making guest-root status equivalent to access across the desktop account.
The lesson closely parallels recent coding-agent sandbox escape research: containment fails at privileged handoffs as often as it fails at the process boundary. An agent may not need direct host syscalls if a mount broker, extension host, helper process, task watcher, or daemon will act on artifacts the agent can influence.
Defensive engineering response
- Use the current remote execution path. Keep Claude Desktop and Cowork updated, and verify that sessions run remotely rather than relying on a historical local VM configuration. Anthropic says remote sessions cannot directly reach the home or company network and can reach local files only through connected folders.
- Minimize connected data. Give Cowork a dedicated working directory instead of a broad home, repository-parent, cloud-sync, or credentials directory. Remote execution changes the route but does not make connected files non-sensitive.
- Assume guest root is attainable. Scope host shares to approved paths, avoid whole-host mounts, and enforce access in a broker outside the guest. A sandbox’s security claim should survive compromise of its guest kernel.
- Disable unnecessary namespace paths. Where local agent VMs are under operator control, restrict unprivileged user namespaces and remove
CAP_NET_ADMINunless workloads demonstrably need them. - Prefer allowlist system-call policy. Deny namespace creation and unnecessary netlink families, and do not expose autoloadable kernel subsystems to an agent by default.
- Reduce the guest kernel surface. Remove or block autoloading of unused modules such as unneeded
net/schedactions, and keep the image on vendor-patched kernels. Patch status is necessary even when the architecture no longer depends on it. - Harden privileged helpers. A root service should not execute binaries whose page-cache state or backing inodes are reachable from an untrusted session. Separate its executable path and filesystem view from agent-controlled data.
- Monitor the remaining action boundary. Anthropic notes that remote isolation limits where code runs, not what Claude can read or do through granted files, applications, browsers, and connectors. Keep consequential tasks on manual approval and investigate unexpected cross-folder or cross-application activity.
SharedRoot demonstrates why agent isolation must be evaluated from untrusted content all the way to host authority. The VM held until the guest kernel did not; after that, the mount architecture decided the outcome. Durable containment comes from arranging the next boundary so that guest root remains just guest root.
Sources: