Claude Cowork SharedRoot沙箱逃逸：Mac本地AI代理虚拟机越狱原理、检测脚本与加固方案

一、事件概述：50万台Mac暴露的本地AI隔离失效风险

2026年7月安全厂商Accomplish AI公开披露代号SharedRoot的高危攻击链。攻击者通过构造提示词诱导Claude Cowork本地执行代码，依托Linux内核漏洞完成虚拟机内权限提升，借助Anthropic内置的VirtioFS全盘挂载通道，直接读写Mac宿主机全部文件。受影响预估约50万启用本地执行模式的Mac用户。

大量开发者存在认知误区：该攻击不是传统Hypervisor虚拟机逃逸。代码始终运行在AVF框架创建的Linux虚拟机内部，没有直接调用macOS原生系统调用。隔离防线崩溃的核心诱因是架构设计缺陷，而非Apple虚拟化框架存在漏洞。

Anthropic收到漏洞报告后，将报告标记为信息性（Informative），拒绝为本地执行分支推送针对性补丁。新版Claude Desktop调整默认策略，Cowork会话默认切换云端运行；用户手动开启本地模式，风险持续存在。

窃取目标高度集中：~/.ssh私钥、云服务商凭证、Kubeconfig、项目.env密钥、浏览器本地缓存、个人文档。整个攻击流程无弹窗授权提示，普通用户无法感知文件被遍历读取。

二、Claude Cowork macOS原生虚拟化安全架构

2.1 官方预设隔离模型

Mac宿主机运行Claude Desktop客户端，依托**Apple Virtualization Framework（AVF）**启动ARM64架构轻量级Linux一次性虚拟机。所有AI自动执行、代码运行操作被约束在Guest虚拟机内部。

官方设计三层防护：

1. 权限隔离：AI会话进程在虚拟机内以普通非特权用户运行；
2. 系统调用限制：Seccomp BPF过滤器拦截高危内核调用；
3. 文件隔离：仅挂载用户手动授权的项目文件夹，预期禁止访问宿主机其他目录。

宿主机coworkd守护进程以root权限管理VirtioFS文件共享，负责宿主机与虚拟机之间文件数据转发。

2.2 致命隐藏配置：全盘宿主机文件系统挂载

架构设计的核心缺陷：除用户手动授权目录外，虚拟机内部预置隐藏挂载点

/mnt/.virtiofs-root

该路径完整映射Mac宿主机根目录/，读写权限等同于Mac当前登录用户。挂载权限被限制为仅虚拟机内root用户可访问。

Anthropic内部将该挂载通道用于组件通信，开发阶段未评估权限提升攻击场景。一旦攻击者拿到虚拟机Guest-Root权限，隔离边界直接失效。

2.3 Mermaid架构图（可直接渲染）

三、SharedRoot完整攻击链路逐环节拆解

整条攻击链由Linux原生特性 + 内核本地提权漏洞 + 不合理文件共享配置串联。不需要远程网络入侵，前提条件：

1. Mac安装Claude Desktop；
2. 用户手动启用Cowork本地执行模式；
3. 用户绑定至少一个本地文件夹；
4. 用户粘贴/接收恶意提示词，诱导AI执行shell代码。

3.1 步骤1：非特权进程创建用户命名空间

会话普通用户调用unshare()生成独立user+network命名空间。该操作不依赖漏洞，属于Linux原生特性。

unshare--user--map-root-user--net

进程在命名空间内部获得虚拟root身份，同时拿到关键能力CAP_NET_ADMIN。
Seccomp过滤器存在宽松策略，未拦截unshare系统调用，攻击链获得启动基础。

3.2 步骤2：通过Netlink触发act_pedit模块自动加载

具备CAP_NET_ADMIN后，攻击者通过Netlink套接字配置流量控制规则，强制内核加载act_pedit数据包编辑模块。

tc qdiscadddev lo root handle1: prio tc filteradddev lo parent1: protocolipu32 match u3200action pedit munge offset0u8 0x00

act_pedit是后续内核漏洞触发的前置依赖。

3.3 步骤3：CVE-2026-46331 Pedit COW本地提权原理

漏洞位于Linux内核net/sched/act_pedit.c，影响5.18 ~ 7.1-rc7版本内核，属于Copy-On-Write机制缺陷。

内核计算可写skb缓冲区范围仅执行一次，无法识别运行时动态解析的数据包偏移。部分写入区域不会生成私有副本，攻击者实现越界写入共享页缓存。

攻击效果：篡改内存中setuid特权二进制镜像，不修改磁盘文件，绕过文件完整性检测。最终将虚拟机普通会话用户提升为虚拟机内部真正root（Guest-Root）。

重要区分：权限提升范围仅限Linux虚拟机内部，无法直接突破AVF虚拟化层执行macOS程序。

3.4 步骤4：访问隐藏挂载点实现跨沙箱文件读写

拿到Guest-Root权限后，直接操作路径：

# 读取Mac宿主机ssh私钥cat/mnt/.virtiofs-root/Users/$USER/.ssh/id_rsa# 遍历用户所有文档目录ls/mnt/.virtiofs-root/Users/$USER/Documents# 窃取云服务商凭证cat/mnt/.virtiofs-root/Users/$USER/.aws/credentials

VirtioFS通道不触发macOS权限弹窗，文件读写行为在宿主机侧无明显告警日志。

3.5 Mermaid攻击流程时序图

四、高频认知误区澄清

1. ❌ 误区：漏洞属于Apple Virtualization Framework逃逸漏洞
   ✅ 事实：AVF虚拟化隔离机制完好。漏洞根源是Anthropic主动将宿主机全盘以读写模式挂载进虚拟机。更换任意虚拟机方案，只要存在同等挂载配置，风险完全一致。

2. ❌ 误区：黑客能远程主动入侵Mac设备
   ✅ 事实：攻击必须人机交互触发。需要用户打开Cowork本地会话，接收恶意提示词。无法通过互联网主动扫描入侵终端。

3. ❌ 误区：拿到Guest-Root就可以运行Mac原生程序
   ✅ 事实：虚拟机是独立Linux系统，仅能读写文件。无法直接执行Mach-O二进制、调用macOS系统API。攻击者只能窃取文件，不能直接植入Mac恶意程序。

4. ❌ 误区：升级Claude客户端可以彻底修复本地模式风险
   ✅ 事实：官方没有修复挂载逻辑，只是修改默认执行模式。用户主动切回本地执行，风险原样保留。

五、本地环境检测脚本（Mac宿主机可直接运行）

脚本功能：识别当前Claude运行模式、检索虚拟机挂载痕迹、检查高风险密钥文件是否暴露，输出风险等级。

使用方式：保存为check_cowork_risk.sh，终端执行bash check_cowork_risk.sh

#!/bin/bash# SharedRoot漏洞风险检测脚本 MacOSset-euopipefailecho"==================== Claude Cowork SharedRoot风险检测 ===================="CLAUDE_PLIST="$HOME/Library/Application Support/Claude/config.json"# 检测Cowork执行模式if[-f"$CLAUDE_PLIST"];thenecho"[1] 读取Cowork配置"MODE=$(jq-r'.cowork.executionMode // "unknown"'"$CLAUDE_PLIST")echo"当前执行模式:$MODE"if["$MODE"="local"];thenecho"⚠️ 风险警告：当前启用本地虚拟机模式，存在SharedRoot攻击面"elseecho"✅ 当前为云端模式，无本地虚拟机逃逸风险"fielseecho"[1] 未找到Claude配置文件，可能未安装Claude Desktop"fi# 检测高危敏感文件echo-e"\n[2] 检测本地敏感凭据文件"SECRET_LIST=("$HOME/.ssh/id_rsa""$HOME/.aws/credentials""$HOME/.kube/config")forfin"${SECRET_LIST[@]}";doif[-f"$f"];thenecho"⚠️ 存在敏感文件$f，本地模式下存在被窃取风险"fidone# 检索虚拟机进程echo-e"\n[3] 检索AVF虚拟机进程"pgrep-fVirtualization.VirtualMachine>/dev/nullif[$?-eq0];thenecho"⚠️ 后台正在运行Linux虚拟机实例"elseecho"✅ 当前无Claude Cowork虚拟机运行"fiecho-e"\n[检测完成] 建议：非必要不开启Cowork本地执行模式"

六、分层加固方案（个人终端+企业运维两套标准）

6.1 普通Mac用户加固（优先级从高到低）

1. 优先使用云端Cowork模式。打开Claude设置，将Cowork执行模式切换为Cloud；
2. 确需本地执行时，仅创建空白独立文件夹授权，禁止授权Home根目录、.ssh、.aws；
3. 单次任务结束立刻关闭Cowork会话，不要长期保持虚拟机后台运行；
4. 不要在会话中粘贴来源不明、包含大量晦涩shell代码的提示词；
5. 定期轮换SSH私钥、云平台访问密钥，怀疑遭遇攻击立即销毁旧凭证。

6.2 开发者/企业终端深度加固

6.2.1 Linux虚拟机内核层面缓解手段（适用于自研AI沙箱场景）

# 禁用非特权用户命名空间（阻断攻击链第一步）sysctl-wkernel.unprivileged_userns_clone=0# 永久生效配置echo"kernel.unprivileged_userns_clone = 0">>/etc/sysctl.confsysctl-p# 黑名单act_pedit内核模块echo"install act_pedit /bin/false">>/etc/modprobe.d/blacklist-pedit.conf update-initramfs-u

6.2.2 VirtioFS安全部署规范（所有本地VM+文件共享场景通用）

1. 禁止挂载宿主机根目录，仅挂载业务所需最小目录；
2. 优先使用只读模式挂载项目目录；
3. virtiofsd启动参数增加沙箱隔离：--seccomp=on --sandbox=chroot；
4. 禁止虚拟机内root自动访问共享文件。

6.2.3 Seccomp策略优化范本

基础原则：由黑名单策略改为白名单策略，直接拦截unshare、clone3、netlink套接字创建，从源头切断攻击链路。

七、延伸思考：本地Agentic AI沙箱架构通用缺陷

SharedRoot漏洞不是孤立事件，它暴露当下本地运行AI Agent普遍存在的设计矛盾。产品团队为追求便捷性，不断放宽隔离边界。

厂商默认假设：虚拟机内部不会出现权限提升漏洞。但Linux内核本地提权漏洞持续稳定产出。只要存在一条通往Guest-Root的路径，配合不受管控的文件共享通道，沙箱隔离等同于形同虚设。

两套可行的安全架构方向：

1. 零共享文件模型：文件数据经由RPC接口中转，不使用VirtioFS/SMB等原生文件共享协议；
2. 能力隔离模型：虚拟机内进程即便提升至root，也无法访问跨宿主机共享资源；

很多AI桌面客户端选择折中方案：默认云端执行，本地模式作为高级选项，并显著提示安全风险，这也是Anthropic当前选择。

八、行业前瞻性结论

随着本地代码执行AI工具普及，文件共享通道逃逸会成为高频攻击向量。传统虚拟机隔离思路已经无法适配AI自主执行多步骤任务的场景。

安全从业者不能继续依赖“虚拟机天然安全”的惯性思维。评估AI沙箱安全性，需要建立全新标准：

1. 权限提升攻击面清单；
2. 宿主机与虚拟机数据交换通道最小权限审计；
3. 攻击链串联风险建模，不能单独评估单个漏洞；
4. 漏洞响应预案，区分“可修复缺陷”与“架构硬风险”。

企业落地本地AI开发助手，应当建立专项准入规范。不允许员工无限制开启本地虚拟机执行模式，重点管控具备文件读写、代码执行能力的Agent功能。

九、互动提问

1. 你日常使用Claude Cowork本地模式还是云端模式？是否留意过文件共享权限范围？
2. 如果需要在Mac本地部署可运行代码的AI助手，你认为什么样的沙箱架构才能平衡易用性与安全性？