Claude Cowork 沙箱：一次有争议的 root 逃逸与本地代码执行之辩

这是什么？

2026 年 7 月 1 日，安全公司 Armadin 公开了一条攻击链：它能在 Anthropic 的 Claude Cowork 用于运行不可信代码的隔离 Linux 沙箱内取得 root shell，并通过第二步解除本应约束该沙箱的网络出站限制。当天 SiliconANGLE、SC Media、GBHackers 等媒体即予以报道。关键的细微之处在于其定性：Armadin 在今年早些时候将该攻击链私下报告给 Anthropic，而 Anthropic 拒绝将其视为安全问题，理由是实施它需要攻击者已经在主机上具备本地代码执行能力。未分配任何 CVE 编号。因此这并非可远程利用的零日漏洞，而是一层防御中被披露的弱点，也是一场关于”沙箱究竟应在攻击者已进入设备时提供多少保护”的真实分歧。

工作原理

按公开描述，这条攻击链有两个概念部分。第一部分是经典的 DLL 侧加载入口（MITRE ATT&CK T1574.002）：已签名的 Claude 桌面二进制文件会先从自身应用目录解析某个系统库，之后才回退到真正的系统副本，因此只要在其旁边放置一个名称与导出函数都符合预期的文件，它便会在一个合法签名的进程内运行。这一步要求攻击者已能在主机上写入文件并执行代码——正是 Anthropic 所援引的前提条件。

第二部分对于智能体开发者更具启发性。沙箱由一个本地特权服务负责置备，桌面应用通过一个进程间通道与之通信。控制会话如何配置的一个参数未经校验即被信任：一个本应强制创建全新的、无特权用户的标志，反而可被切换为复用一个任意命名的账户，而该服务会在不加检查的情况下满足一个指向超级用户的请求。其结果是在容器内得到一个 root shell，而非设计所预期的受限用户。一个相关缺陷还允许调用方关闭本应阻止沙箱联系任意主机的出站过滤。我们刻意描述该缺陷的形态，而非复现其参数，因为有用的教训在于架构，而非配方。

为何重要

分歧本身就是重点。Anthropic 的立场——一次以预先存在的本地代码执行为前提的沙箱逃逸不算漏洞——是站得住脚且常见的：如果攻击者已经以你的身份运行代码，他本就能读取你的文件与密钥，沙箱从来就不是你最后的防线。Armadin 隐含的反驳则是纵深防御的论点：Cowork 的核心价值主张正是运行不可信内容，而一层仅凭单个未校验标志便能从无特权跃升为 root、从受限网络转为不受限的隔离层，其边界比设计所暗示的要脆弱。二者可以同时成立。对任何交付可执行代码的智能体的人而言，真正要紧的是：为你置备沙箱的那个特权辅助服务，本身就是攻击面的一部分；而信任来自低权限调用方的参数，等于在崭新的 AI 运行时核心处重现了一个存在数十年的”混淆代理”模式。签名二进制这一角度同样重要：攻击者看重在受信任的签名进程内执行以躲避检测，而 AI 桌面应用如今已是高价值主机，因为它们持有 API 密钥、云凭据，以及智能体所连接的一切访问权。

防御

对于构建或运营智能体沙箱的团队，应将本地置备服务视为一道安全边界，校验它从应用收到的每一个参数，尤其是任何选择用户、特权级别或网络策略的参数；请求 root 的调用应直接拒绝，而非满足。要假定沙箱终会被逃逸，并叠加能够在逃逸后仍然有效的层次：最小权限的主机账户、在容器之外且调用方无法左右之处强制执行的出站过滤，以及对沙箱进程突然以 root 运行或联系意外主机的监控。要抵御 DLL 侧加载，可从固定的系统路径解析系统库、启用安全的库搜索顺序，并对应用目录进行签名与完整性校验，使放置在签名二进制旁的文件能被发现。对终端用户而言，教训不变：让运行智能体桌面应用的主机保持更新并远离不可信代码，因为在这类问题上，主机就是信任之锚。若你在企业中运行 Claude Cowork，请部署能检测本地代码执行以及对应用目录未授权写入的终端控制，因为那正是整条攻击链所依赖的前提。

状态

Armadin 于 2026 年 7 月 1 日公开，此前在今年早些时候私下报告给 Anthropic。Anthropic 回应称不将该攻击链视为安全问题，因为利用它需要在主机上预先存在本地代码执行；未分配 CVE，也未宣布补丁。

项目	详情
公开	Armadin 报告，2026 年 7 月 1 日
产品	Claude Cowork 沙箱（Windows 主机上的 Linux 虚拟机）
入口	向已签名桌面二进制的 DLL 侧加载（T1574.002）
提权	未校验的会话置备参数 → 沙箱内 root；出站过滤绕过
前提条件	攻击者已在主机上具备本地代码执行能力
厂商定性	不视为安全问题；无 CVE，未宣布补丁