SPR{K}3back to research

SharedRoot: One Short Prompt, Every File on the Mac

July 24, 2026 · SPR{K}3 Research

A researcher connects a folder to a fresh Claude Cowork session, types one short message, and watches the agent walk out of the disposable Linux VM it was supposed to be trapped inside and read or write any file on the Mac as the logged-in user — SSH keys, cloud credentials, browser stores. No permission prompt.

That is SharedRoot, disclosed yesterday by Accomplish AI. Roughly 500,000 macOS users running local Cowork sessions were exposed. Anthropic closed the report as "informative" — no fix. Cowork now defaults to cloud execution, sidestepping this chain. Users who opt into local execution are still in the same place.

The architecture, and where it broke

Per Accomplish's writeup, Cowork's Mac app runs a Linux VM per session via Apple's Virtualization framework. Each session gets a disposable unprivileged user and a seccomp filter. Folders the user connects are shared in by a root daemon, coworkd.

The design assumption that failed is one line:

The entire host /, mounted so that only guest-root inside the VM can see it, at /mnt/.virtiofs-root.

Read-write. Any path to guest-root is a path to full read/write on the host /. The seccomp filter, the disposable user, the folder-scoping when the user connected one directory — none of it binds the agent if it can reach guest-root.

The chain is four boring steps:

  1. Create a user namespace plus a network namespace. That grants CAP_NET_ADMIN inside the private network namespace — a normally-privileged capability now available to an ordinary user.
  2. With CAP_NET_ADMIN, autoload the kernel's act_pedit traffic-control packet-editing subsystem.
  3. Exploit CVE-2026-46331 — the pedit COW flaw in act_pedit (TuxCare, Red Hat) — to gain guest-root.
  4. Read or write host / as the logged-in Mac user.

No prompt injection. No jailbreak. The agent produces a legal syscall sequence and the kernel behaves as specified. The failure lives in the sandbox author's mental model of what the sandbox contained.

Why this keeps happening

SharedRoot is the fourth AI-agent sandbox failure in six weeks where the sandbox builders were wrong about what it contained:

As Accomplish's Oren Yomtov puts it:

act_pedit is one bug in a category. The Linux net/sched subsystem throws off this exact shape of privilege escalation on a regular cadence: an autoloadable module, a config path an unprivileged user can reach, a memory bug at the end of it. Patch this one and you've fixed this one. The chain re-arms on the next one, with everything above the kernel untouched.

This isn't a patch-faster problem. You're structurally one bug behind, all the time.

The interesting failure is never the specific bug; it is that the boundary the sandbox designer thought they had drawn does not match the surface the agent can reach.

Where a fix has to live

Accomplish's fixes for Cowork close each step: disable unprivileged user namespaces in the guest, tighten seccomp, stop autoloading kernel modules on demand, scope host-filesystem sharing to just the folders the user connected (read-only where possible), and run coworkd with ProtectSystem=strict in its own mount namespace so a compromised session user cannot poison the binaries it re-execs.

They all live outside the model, at the boundary between the agent's process and the OS. The question SharedRoot poses is not "does the model refuse to run act_pedit?" — the syscalls are legal. It is "does anything watch what the agent does at the process and kernel-interface boundary?" On every AI-agent product shipping a local sandbox VM, the answer is: whatever the vendor's containment layer says, plus zero.

The takeaway

Every AI-agent product with a local sandbox — Cowork, Cursor, Copilot CLI, Codex, Gemini CLI — runs on the same substrate. The kernel is autoloadable. The next act_pedit-shaped bug is somewhere in net/sched, eBPF, or netfilter, unmerged.

That is what runtime behavioral monitoring exists for. Not "does the model refuse?" — wrong layer. But "did an agent process just autoload a rare kernel module, create a user namespace, and open a path outside its workspace?" has an answer.

Anthropic marked this "informative." Five hundred thousand local sessions are still exposed. The chain is still there.

Sources

SPR{K3 is a security research operation that pairs offensive vulnerability research with runtime behavioral defense. Defend is our runtime agent. To talk about a deployment, reach us at support@sprk3.com.