AINEWS
Researchers at Accomplish AI used a Linux kernel bug to break out of the agent's Mac VM and reach SSH keys and cloud credentials. Anthropic's fix: default to cloud execution.
Anthropic's Claude Cowork agent escaped its sandbox and read files on the host Mac. A research team at Accomplish AI connected a folder to a fresh Claude Cowork session, sent one short message, and watched the agent break out of the Mac-hosted Linux virtual machine it was supposed to be confined to. From inside the VM, the agent read and wrote files across the user's home directory on the underlying Mac, with no permission prompt.
"From inside the VM, it reached the host Mac and read and wrote files all over it, far outside the folder we'd connected, with no permission prompt anywhere," Oren Yomtov, principal security researcher at Accomplish AI, told The Hacker News. With that level of access, the agent can read SSH keys, cloud credentials, and any other data stored under the logged-in Mac user.
The team named the chain SharedRoot and published the full technical writeup on the Accomplish AI blog. The Hacker News reported that about 500,000 macOS users were running local Cowork sessions before Anthropic changed the default. The report was filed through Anthropic's coordinated vulnerability disclosure process.
Cowork's macOS desktop app runs as the logged-in user, but the agent itself runs inside a Linux VM created with Apple's Virtualization framework. Each session gets a throwaway unprivileged user wrapped in a Secure Computing Mode (seccomp) filter, and the folders the user connects are brokered into the VM by a root daemon called coworkd.
The load-bearing detail, per the Accomplish writeup: the entire host filesystem, including /, is shared into the VM read-write, mounted at /mnt/.virtiofs-root and visible only to guest-root inside the VM. "The entire host '/,' mounted so that only guest-root inside the VM can see it," Yomtov said. Any path to guest-root is a path to the host.
The chain walks that path. The session user calls unshare to create a new user namespace, which Linux permits by default. Inside the namespace it briefly holds CAP_NET_ADMIN. With that capability it configures a traffic-control (tc) action that references the act_pedit kernel module, which the kernel autoloads. The agent then exploits CVE-2026-46331, a kernel flaw called "pedit COW" disclosed in June, to poison the page cache of a root-owned helper binary the session can read but not write. When coworkd re-execs that helper as part of normal work, it runs the poisoned copy as root. The session user is now root inside the guest, can see the host mount, and can read or write anything the Mac user can.
"Creating user and network namespaces gives the session CAP_NET_ADMIN within its private network namespace, allowing it to perform various network-related operations," Accomplish co-founder and CTO Or Hiltch told The Hacker News. "That capability provides access to the vulnerable tc/act_pedit kernel path used by pedit COW."
Anthropic closed the report as "informative" without issuing a direct fix to the local sandbox, the Accomplish writeup and The Hacker News both confirm. The current version of Claude Cowork defaults to cloud execution, which does not run on the user's machine and so removes this particular path.
Users who opt to keep Cowork running locally remain exposed. That is the part the broader coverage underplays: Anthropic's "fix" is a configuration change for new installs, not a security patch for the local sandbox.
The deeper point, per the Accomplish research, is that act_pedit is one bug in a recurring pattern: an autoloadable kernel module, a config path an unprivileged user can reach, a memory bug at the end of it. AI-assisted vulnerability research has industrialized finding the next one. "At any given moment there's likely a privilege-escalation bug it's still exposed to, sometimes fixed upstream but not yet in your image, sometimes not yet fixed anywhere, with a working exploit out within hours," Yomtov said. "This isn't a patch-faster problem. You're structurally one bug behind, all the time."
So the mitigation has to live above the kernel. The four choices, each of which breaks the chain on its own, are:
apparmor_restrict_unprivileged_userns=1 or kernel.unprivileged_userns_clone=0 and the session user never gets into a namespace where it holds CAP_NET_ADMIN.unshare, setns, clone3, and AF_NETLINK.install ... /bin/false for any module the guest does not need, including act_pedit.coworkd with ProtectSystem=strict in its own mount namespace, and share only the folders the user actually connected, not the whole host.Do those and the chain has nowhere to land, even if a future kernel bug replaces act_pedit in step four.
Anyone running Claude Cowork locally should treat the host filesystem as reachable from inside the session. The fastest hardening path is the namespace and seccomp changes, which do not require an Anthropic update. The structural fix is to move to the cloud-default execution path that Anthropic has now made the default; local mode is still a setting, and it is still exposed.
The next public agent-sandbox escape is, by the same logic, already in someone's exploit kit. Whether Anthropic adds local-mode defenses beyond mount scoping and a tighter seccomp posture is the watch item.