上周我们讨论了 GPT-5.6 Sol 因为一个没设置的 sandbox flag，在 72 小时内误删了多个开发者的文件和数据库。那条推文获得了 550 万次浏览，整个技术圈都在讨论「AI Agent 该不该有文件系统访问权限」。

如果你以为给 Agent 套上沙箱就万事大吉了，这篇文章可能会让你重新坐直。

Pillar Security 的安全研究团队花了几个月时间，在 Cursor、OpenAI Codex、Google Gemini CLI 和 Antigravity 这四款最流行的 AI 编程助手中，找到了 7 种沙箱逃逸方法。他们没有攻击沙箱本身，甚至没有尝试绕过任何安全边界。他们只是让 Agent 写了一个文件，然后静静地等着宿主系统上的可信工具自己去执行它。

这 7 个发现被整理成一个系列，叫做「沙箱逃逸周」（Week of Sandbox Escapes），每天揭露一种新的攻击面。

问题的本质：文件不是惰性的#

所有 AI 编程助手的沙箱都画了一条看似清晰的线：Agent 在项目工作区内是可信的，宿主系统在外部是受保护的。这条线的逻辑是，「Agent 不能直接运行系统命令，所以它无法危害宿主」。

但 Pillar 团队揭露了一个被忽视的事实：工作区内的文件不是惰性的。

你的 IDE 和 CLI 工具无时无刻不在沙箱外运行自己的组件：Python 扩展在解析解释器路径，Git 集成在扫描仓库元数据，VS Code 在执行任务配置文件，hook 引擎在触发命令钩子，Docker Desktop 在暴露本地 socket。这些东西都是可信的，它们在沙箱外运行，而且它们会读取工作区里的文件。

一个被沙箱约束的 Agent 可以完全遵守所有规则，同时精确地塑造那些被宿主组件读取的文件内容。攻击触发点呢？Prompt Injection，一段恶意指令藏在 README、Issue、依赖描述或 diff 里，它自己不会执行任何命令，但它会让 Agent 写下一个文件，这个文件随后被沙箱外的可信工具加载、解析或运行。逃逸就这样发生了，Agent 全程没出过沙箱。

Pillar 将这 7 个发现归纳为四种失败模式，每一种都值得开发者认真对待。

四种失败模式#

模式一：配置文件即代码#

这类攻击利用了「配置文件」和「可执行代码」之间模糊的边界。

Cursor 的第一个漏洞（CVE-2026-48214）出在 .claude hook 配置上。Agent 可以操作工作区内的这个文件，而 Cursor 的 hook 引擎在沙箱外读取并执行它。攻击链路很简单：恶意 Prompt → Agent 写入 hook 配置 → Hook 引擎在沙箱外执行任意命令。修复已在 Cursor 3.0.0 中发布。

第二个 Cursor 漏洞更隐蔽：Agent 修改了虚拟环境的解释器路径，然后编辑器的 Python 扩展在发现解释器的过程中自行执行了它。Agent 没有运行任何命令，它只是编辑了一个路径字符串，而 Python 扩展把那个路径当作合法的解释器去调用了。

第三个 Cursor 漏洞利用了一个 Git 的冷知识：Git 元数据目录不一定叫 .git。通过 fsmonitor 机制，攻击者可以让 Git 执行工作区内的任意脚本，而 Cursor 基于路径的沙箱规则只拦截了 .git 目录。这个漏洞同样在 3.0.0 中修复，CVE 正在分配中。

模式二：白名单信名不信实#

这类攻击的核心问题是：命令白名单检查的是命令「名字」，而不是命令的「行为」。

Codex CLI 团队的案例最典型。它维护了一个「安全命令」白名单，git show 被列为只读操作。但 Pillar 团队发现，git show 的实际调用并不是只读的，攻击者可以通过构造特定的 Git 对象，让 git show 触发任意命令执行。白名单信任了 git show 这个名字，但没有验证它在特定参数下的真实行为。

OpenAI 在 v0.95.0 中修复了这个问题，支付了一笔高危漏洞赏金。但这件事暴露了一个系统性问题：你在白名单里写的是命令名，但命令名下面藏着的是一个图灵完备的解释器。

模式三：拒绝名单永远追不上操作系统#

这类攻击针对的是基于文件系统路径的拒绝名单。沙箱规则说「禁止访问 /etc、/var、/tmp」，但攻击者找到了规则没覆盖到的路径。

Antigravity 的第一个漏洞利用了 macOS Seatbelt 拒绝名单的一个盲区。Seatbelt 是 macOS 的沙箱框架，它通过配置文件指定禁止访问的路径。Pillar 团队找到了一条映射到敏感系统资源的非标准路径，这条路径不在拒绝名单上，Agent 可以通过它逃逸到宿主。

Google 将这个问题归类为「其他有效的安全漏洞」但做了降级处理，理由是攻击需要社会工程学辅助，用户需要先信任一个携带恶意 prompt 的仓库。

模式四：特权守护进程在沙箱之外#

Docker socket 漏洞同时影响了 Codex、Cursor 和 Gemini CLI，是这次研究中波及面最广的一个发现。

问题很简单：Docker Desktop 在本地暴露了一个 Unix socket，具有 root 等效权限。这个 socket 不在任何 AI 编程助手的沙箱范围内，因为它属于宿主层的系统服务。但 Agent 可以访问它，通过挂载卷、文件复制或网络调用，然后在这个完全不受沙箱约束的环境里执行任意代码。

一个 Agent 遵守了所有规则，没有运行任何被禁止的命令，但它向 Docker socket 发送了一个创建容器的请求，容器里执行了攻击者想要的任何东西。这个漏洞已经修复，但它的存在暴露了一个根本性的威胁模型问题：AI 编程助手的沙箱设计假设攻击面仅限于进程本身，但忽略了沙箱外的特权服务。

不是第一次，也不会是最后一次#

这类攻击模式其实并不新鲜。早在今年 4 月，Cymulate 就记录了同样的模式，他们称之为「基于配置的沙箱逃逸」（Configuration-Based Sandbox Escape），影响了 Claude Code、Gemini CLI 和 Codex CLI。攻击原理是一样的：Agent 写入一个文件，这个文件在下次启动时被宿主执行。

Pillar 的贡献在于广度。他们证明这不是单一工具的疏忽，而是一个跨厂商、跨架构的系统性问题。当四个不同的 AI 编程助手以四种不同的方式实现沙箱，却暴露出相同的攻击面时，问题就不在个别实现上了，问题出在威胁模型本身。

Pillar 的解法：不看文件，看行为#

Pillar 没有给出一个更长的禁止文件名列表。他们的建议更根本：不要盯着 Agent 写了什么文件，去监控宿主工具「何时」运行了「Agent 写的东西」。

换句话说，安全边界应该从「Agent 不能做什么」转移到「宿主工具在处理什么」。当一个 Python 扩展开始解析一个工作区内的解释器路径时，当 Git 开始读取一个非标准位置的元数据目录时，当 hook 引擎加载了一个被修改过的配置文件时，这些时刻才应该是安全检查的触发点。

对于正在评估 AI 编程工具的开发者和安全团队，Pillar 给出了一个更实用的判断标准：不要问「这个工具有沙箱吗」，去问「写入沙箱内的文件离开沙箱后会发生什么」。

给开发者的实操建议#

基于 Pillar 的研究和当前各工具的修复状态，以下是几条可操作的建议：

1. 升级到最新版本。 大部分漏洞已在最新版本中修复。Codex CLI 用户需升级到 v0.95.0+，Cursor 用户需升级到 3.0.0+。这不是可选的。

2. 审查项目的 hook 和配置文件。 在信任一个开源仓库之前，检查它的 .claude、.vscode、.cursor 等隐藏配置目录。这些文件可能在 AI Agent 介入之前就存在，也可能是在你打开项目后被 Agent 写入的。

3. 限制 Docker socket 访问。 如果你在开发环境中运行 Docker Desktop，考虑对 AI 编程工具的网络访问做限制。Docker socket 是 root 等效的，任何能访问它的进程都等于拥有宿主的 root 权限。

4. 监控文件变更模式。 关注工作区内非源码目录的意外变更，尤其是 .git 配置、解释器路径、hook 脚本和任务配置文件。

5. 理解 Prompt Injection 的威胁面。 攻击不需要 Agent 主动作恶，它只需要 Agent 忠实地执行了一段被污染的自然语言指令。这意味着任何一个 Issue、PR 描述、README 或依赖元数据都可能成为攻击载体。

写在最后#

Pillar Security 的「沙箱逃逸周」是 2026 年 AI 安全领域最重要的研究之一。它的价值不在于发现了多少 CVE，而在于揭示了威胁模型的根本缺陷：当 AI Agent 被赋予文件写入能力时，它就不再是一个封闭的执行单元，而是整个工具链中的一个数据源。任何一个读取这些文件的宿主组件，都可能成为一个无意的执行者。

上周我们说，AI Agent 需要沙箱。这周 Pillar 告诉我们，有沙箱还不够，你需要理解沙箱边界上正在发生什么。

参考来源：