---
title: "SharedRoot: Anthropic Closed the Claude Cowork Sandbox-Escape Report as 'Informative'"
date: 2026-07-26
tags: ["security","claude-cowork","sandbox-escape","linux-kernel","vulnerability-disclosure","anthropic"]
categories: ["AI Tools","Industry"]
summary: "Security firm Accomplish disclosed SharedRoot on July 23: a six-step exploit chain that escapes Claude Cowork's local macOS sandbox and reads/writes anywhere on the host filesystem, affecting an estimated 500,000 local-execution users. Anthropic closed the report as 'Informative' without shipping a fix — the exposure is only sidestepped because Cowork now defaults to cloud execution, leaving anyone who opts into local mode still exposed."
---


![SharedRoot: Anthropic Closed the Claude Cowork Sandbox-Escape Report as 'Informative'](/images/claude-cowork-sharedroot-sandbox-escape.png)

Claude Cowork runs your agent's code inside a per-session Linux VM on your own Mac, using Apple's Virtualization framework — the whole point being that if the agent goes rogue or gets prompt-injected, the damage stays inside the VM instead of reaching your real filesystem. On July 23, security firm Accomplish published **SharedRoot**, a six-step exploit chain that breaks exactly that guarantee: an unprivileged process inside the VM can escalate to guest-root and reach the entire host Mac, read-write, no permission prompt. Anthropic's response, per Accomplish's own account, was to close the report as "Informative" and not ship a fix. This is the second time in four months Anthropic has told a researcher a Cowork sandbox-escape chain doesn't qualify.

## How SharedRoot Works

Researcher Oren Yomtov's writeup lays out the chain in six steps. An unprivileged session user inside Cowork's guest VM creates a new user namespace — becoming root within that namespace — and gains `CAP_NET_ADMIN`. From there it loads the Linux kernel's `act_pedit` traffic-control packet-editing module via a netlink socket and exploits **CVE-2026-46331** ("pedit COW"), a real, CVE-tracked page-cache-poisoning bug patched across Ubuntu, Debian, SUSE, Red Hat, and Amazon Linux, to corrupt a root-owned binary. That corrupted binary gets re-executed by `coworkd`, Cowork's privileged host daemon, during a routine process re-exec. The payoff: the entire host filesystem is mounted read-write into the guest VM at `/mnt/.virtiofs-root`, so guest-root is effectively host-root for file access purposes. As Yomtov put it, "one detail matters more than the rest: the host filesystem gets shared into that VM read-write."

CVE-2026-46331 itself isn't exotic — it's a mainline Linux kernel bug in the `net/sched` subsystem, CNA-assigned June 16, with a public proof-of-concept ("packet_edit_meme") circulating within a day. What makes SharedRoot notable isn't the kernel bug; it's that Cowork's own architecture — a full read-write host mount, reachable by anything that gets guest-root — turns a generic Linux privesc into "read your SSH keys and cloud credentials from any agent session that gets compromised." The Hacker News, which Accomplish briefed ahead of publication, reported roughly 500,000 macOS users running local Cowork sessions were affected prior to the exposure being narrowed.

## Anthropic's Answer: "Informative," Not a Fix

Per Accomplish, Anthropic closed the disclosure as "Informative" — its bounty-program label for findings that don't count as actionable, in-scope vulnerabilities. The company's stated reasoning: CVE-2026-46331 fell inside the program's 30-day window for bugs published shortly before the report, and Anthropic read the specific hardening items as "defense-in-depth" rather than a standalone vulnerability worth patching directly. No dedicated Anthropic statement, blog post, or on-record spokesperson comment about SharedRoot exists anywhere I could find — what's public is Accomplish's account of a closed bounty ticket, not a company response.

The practical mitigation that exists today isn't a patch — it's a product default that shipped for unrelated reasons. Cowork's newest builds default to cloud execution instead of local, which routes agent code off the user's Mac entirely and sidesteps the VM-escape path by construction. Anyone who opts into local execution — presumably for latency, offline use, or just not knowing cloud is now the default — remains exposed to the full chain, unpatched, today.

## This Isn't the First Time

Four months earlier, a different company hit the same wall from a different angle. Armadin — founded by Mandiant's Kevin Mandia — reported a Windows-side Cowork sandbox escape on March 20: DLL sideloading chained into root execution via `CoworkVMService`. Anthropic's response, on March 24, was that the chain "did not qualify because pulling it off requires an attacker to already have local code execution on the host machine" — a different rationale, same outcome. Two independent security firms, two different platforms (Windows and macOS), two different bug classes, four months apart, and in both cases Anthropic's assessment was that the reported chain sits outside what its bounty program treats as fixable.

Read individually, either rejection has a defensible internal logic — bounty programs draw scope lines for a reason, and "attacker needs local code execution already" or "this CVE is inside our grace window" aren't crazy arguments in isolation. Read together, they describe a pattern: the specific promise Cowork's local-VM architecture makes — agent code stays contained even if the agent misbehaves — has now been broken twice by outside researchers, and twice Anthropic's answer has been that the breaking chain falls outside scope rather than that the containment model needs hardening.

## Why This Matters Beyond One Product

This blog has been consistently pro-Claude Code on architecture — terminal-native execution and explicit resource-scoped controls like `sandbox.credentials` are real structural advantages over IDE-embedded competitors, not marketing. That argument gets harder to make cleanly when the pattern for Cowork specifically is two rejected sandbox-escape reports in four months, both closed on scope technicalities rather than resolved by hardening the underlying containment boundary. The `sandbox.credentials` model earns credit precisely because it's a resource-level guard that doesn't depend on an attacker failing to find a chain — it blocks the read outright. SharedRoot is a reminder that Cowork's local-execution path doesn't yet have an equivalent: the containment boundary is the VM itself, and the VM's own filesystem mount is the thing that keeps getting broken.

The honest read: cloud-default execution is a real mitigation, not a dodge, and most Cowork users are probably on it already. But "the fix is that most people aren't using the vulnerable mode anymore" is a different claim than "the vulnerability is fixed," and conflating the two is exactly the kind of gap this blog calls out when other vendors do it. Anthropic's Claude Code team has shipped patches for prior symlink and sandbox-boundary findings (including hardening that predated a since-disclosed GhostApproval report by nine days) at a cadence this blog has praised directly. Whether that same rigor extends to Cowork's local-execution VM boundary — rather than relying on a product-default change to quietly absorb the risk — is the thing worth watching next.

---

**Sources:**
- [Accomplish: SharedRoot — Escaping Claude Cowork's Sandbox](https://www.accomplish.ai/blog/sharedroot-escaping-claude-cowork-sandbox/)
- [The Hacker News: Claude Cowork Flaw Could Let AI Agent Escape Its Sandbox](https://thehackernews.com/2026/07/claude-cowork-flaw-could-let-ai-agent.html)
- [SiliconANGLE: Armadin Details Full Sandbox Escape in Claude Cowork, Anthropic Disputes Risk](https://siliconangle.com/2026/07/01/armadin-details-full-sandbox-escape-claude-cowork-anthropic-disputes-risk/)
- [Anthropic Engineering: How We Contain Claude Across Products](https://www.anthropic.com/engineering/how-we-contain-claude)
- [Claude.com: The Claude Cowork Product Guide](https://claude.com/blog/the-claude-cowork-product-guide)
- [CVE-2026-46331 — NVD Record](https://nvd.nist.gov/vuln/detail/CVE-2026-46331)