Claude Cowork Sandbox Escape: How SharedRoot Let an AI Agent Access Files Outside Its VM

Researchers connected one folder to a fresh Claude Cowork session, sent a single short message, and watched their AI agent walk straight out of its “sandboxed” Linux virtual machine — into the host Mac’s SSH keys, cloud credentials, and everything else the logged-in user could touch. Anthropic reviewed the report and closed it as “Informative.” Here’s exactly how it worked, and why that response is more defensible than it sounds.

What the Researchers Actually Did

Oren Yomtov, principal security researcher at Accomplish AI, described the test plainly in his own writeup: “We connected a folder to a fresh Claude Cowork session, sent one short message, and watched the agent escape the sandbox. 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. SSH keys, cloud credentials, anything the user’s account can touch.”

They named the attack chain SharedRoot. According to Accomplish, roughly 500,000 macOS users running Claude Cowork locally were exposed before Anthropic’s newer default — cloud-based execution instead of a local VM — sidestepped the specific path they found.

What “Sandboxed” Was Supposed to Mean

Claude Cowork’s design, on paper, is careful. The macOS app runs under your normal user account, but the actual agent work happens somewhere else entirely: a Linux virtual machine, spun up through Apple’s own Virtualization framework. Inside that VM, each session gets a disposable, unprivileged user account, restricted by a seccomp filter — a Linux kernel feature that limits which system calls a process is allowed to make. The folders you explicitly connect are brokered in as mounts by a root-level daemon called coworkd.

That’s the promise: an unprivileged user, restricted system calls, and only the folders you chose to hand over, visible inside the VM. Yomtov’s own framing of why that boundary matters is worth reading directly: “Untrusted input isn’t an edge case for an agent, it’s the main case. You want it reading the repo you didn’t write and the PDF someone emailed you. So the boundary is the only thing standing between ‘the model did something silly’ and ‘the model had my cloud credentials.'”

A different, separate sandbox escape incident from the same week — OpenAI’s own internal model breaking out of an evaluation environment. Included for context on how common this failure pattern has become across the industry, not as coverage of the Claude Cowork case specifically. Independent production, not affiliated with Wangdoo.

The One Detail That Changed the Outcome

Here’s the part that determined how the rest of the chain played out. The entire host Mac filesystem — the real root directory of your actual computer — was mounted read-write inside that Linux VM, at a path called /mnt/.virtiofs-root. Visible only to whichever account held root privileges inside the guest VM, but present in full. Not the connected folder. Not a scoped subset. The whole machine.

How the Escape Actually Worked, Step by Step

Yomtov’s writeup walks through six distinct steps, and the striking part is how few of them involved anything resembling a conventional “hack.” Reproduced and explained in order:

1. Start as the unprivileged session user. No exploit needed here — this is simply Cowork doing its normal job on whatever content it was given.
2. Get elevated capabilities inside a new namespace. The session user calls a standard Linux function (unshare) to create a fresh user namespace. Inside that new namespace, the same user is treated as root, with a full set of Linux capabilities — including one called CAP_NET_ADMIN. The guest VM allowed unprivileged users to create these namespaces at all, which Yomtov notes plainly wasn’t a bug: “It’s a kernel feature that could have been turned off, but left on.”
3. Reach vulnerable kernel code. With that networking capability in hand, the session configures a traffic-control action using a kernel module called act_pedit — normally used for advanced network packet editing, something a sandboxed coding assistant has no real reason to touch. Merely referencing the module was enough to make the kernel automatically load it, over a communication channel the sandbox’s security filter happened to permit.
4. Turn a known bug into a write primitive. That freshly loaded module was vulnerable to CVE-2026-46331, nicknamed “pedit COW” — a publicly disclosed Ubuntu kernel bug from June 2026. It allowed the session to corrupt the cached, in-memory copy of a file it could read but not normally modify, without ever touching the file’s actual bytes on disk — which is part of what made the attack quiet.
5. Turn that into full root inside the guest. This is the step where Yomtov says it stops being purely a kernel bug and becomes a design failure. The coworkd daemon runs as root, and in the ordinary course of its work, it re-executes a helper program — the same helper the session had just poisoned in memory. Because the process launching that helper was already root, a Linux protection called NoNewPrivs — designed specifically to stop privilege escalation across this kind of handoff — had nothing left to block. The session user was now root inside the guest VM.
6. Walk out through the open door. Guest-root could see /mnt/.virtiofs-root — the entire host filesystem, mounted read-write. From there, it read and wrote files across the real Mac directly, with the full permissions of whichever person was logged in.

Accomplish ran the complete chain end-to-end on their own test machine. It worked.

Why the Kernel Bug Isn’t Really the Point

This is the argument Yomtov makes most forcefully, and it’s the part that elevates this from a routine “vulnerability found, vulnerability patched” story into something more useful. act_pedit is one specific bug. But the broader category it belongs to — Linux’s networking subsystem throwing off exactly this shape of privilege-escalation flaw — recurs on a regular basis. Patch this particular module and, in his words, “the chain re-arms on the next one, with everything above the kernel untouched.”

He backs that up with a striking data point about the current pace of this category of research: by one analysis he cites, mainline Linux kernel privilege-escalation advisories are running at roughly 2.3 times the prior year’s rate, and the gap between a fix landing publicly and a working exploit appearing has collapsed to a matter of hours. His conclusion: “You’re structurally one bug behind, all the time.”

The Four Fixes That Would Have Stopped It — Any One of Them

Rather than simply flagging the CVE, Yomtov’s disclosure lays out four independent design decisions, each of which alone would have broken this specific chain — and, more usefully, each of which closes off an entire category of future kernel bugs rather than just this one:

Why Anthropic Closed the Report as “Informative”

Accomplish reported the full chain to Anthropic. Anthropic’s response, according to Yomtov’s own account, was to close it as “Informative” rather than treat it as a standalone vulnerability requiring a dedicated fix — citing two specific reasons: the underlying kernel CVE fell within the disclosure programme’s standard exclusion window for bugs published in the prior 30 days, and the four hardening recommendations were categorised as defense-in-depth measures rather than a discrete vulnerability in Cowork itself.

Yomtov’s own reaction to that decision is notably measured rather than combative: “That’s a reasonable call for a bounty program. But a program’s scope and your exposure on your own laptop are different questions.” He’s making a specific, narrower point — that relying on upstream kernel fixes to arrive on their own schedule means, from an end user’s perspective, “the strength of the box is tied to a patch race you don’t run and can’t win.”

My Take — Mr Wangdoo

What stands out to me about this disclosure isn’t the exploit chain itself — six steps, one CVE, competently documented, the kind of thing security researchers publish regularly. It’s how unusually generous Yomtov is toward the vendor’s response, and how that generosity is actually the more interesting story than the bug.

Most security disclosures I read fall into one of two registers: breathless alarm, or quiet technical detail with an implied “and this is scandalous” left for the reader to infer. This one does neither. Yomtov explicitly calls Anthropic’s “Informative” classification a reasonable call for a bug bounty programme, while still making a sharp, separate point that a programme’s scope and an individual user’s actual exposure are two different things that shouldn’t be confused with each other. That’s a more useful distinction than most security writing bothers to draw, and it’s worth sitting with: a company can make a defensible policy decision about what its bounty programme covers, and that decision can still leave real users carrying real risk in the gap.

The four-fixes framing is the part I’d want any engineering team building on top of AI agents to actually internalise, regardless of which vendor they use. Patching one CVE fixes one CVE. Yomtov’s argument — that Linux kernel privilege-escalation bugs in this exact shape are arriving at more than twice last year’s rate, with exploit code often following within hours of disclosure — means any sandbox whose safety depends on “the guest kernel stays clean” is making a bet it will eventually lose, repeatedly, on a schedule it doesn’t control. The fixes that actually matter are the ones that hold even when the next kernel bug — not this one, the next one — inevitably shows up. That’s a more durable way to think about AI agent security than chasing each new CVE as it lands, and it’s the one lesson from this disclosure that applies well beyond Claude Cowork specifically.

Frequently Asked Questions

Clayton Samuel (Mr Wangdoo), QFA

Founder and editor, Wangdoo.com. Qualified Financial Adviser with a background in electronics, web development, and cloud infrastructure. This article is based on the original security researcher’s disclosure and independent technical reporting. No interviews were conducted; no product is promoted.