沙箱逃逸之周：当智能体编写宿主机所运行的内容

2026年7月20日，Pillar Security 发布了一个由七部分组成的系列文章，展示如何在不攻击沙箱本身的情况下，将四个 AI 编程智能体——Cursor、OpenAI Codex CLI、Google Gemini CLI 和 Google Antigravity——引出其沙箱之外。在每一条攻击链中，智能体都遵守了自身规则，并写入一个普通的项目文件：一个 hook 配置、一个 virtualenv 解释器、一项 Git 设置、一个 VS Code 任务。随后，编辑器或 CLI 中一个未受沙箱约束的组件会在宿主机上加载、扫描或运行该文件。Pillar 表示，它在数月间复现了这些绕过手法，并向三家厂商报告，而三家厂商的回应各不相同；目前尚无在野利用的报告，也未记录任何实际危害。完整记录及其严重程度与置信度评级，收录于Orca AI 事件档案中，与其他归入 SANDBOX 类型标签的条目并列。

边界分为三层，而第三层会泄漏。

Pillar 的概述将一个沙箱划分为三层而非一层：智能体进程可以直接运行什么、它可以在工作区内创建或更改哪些文件，以及未受沙箱保护的宿主组件随后会如何处理这些文件。研究人员指出，大多数产品只保护了第一层，并假定第二层对第三层毫无影响。在开发者机器上，这一假定并不成立——在智能体周围，编辑器里充满了读取项目状态并据此采取行动的自动化机制：解析解释器的 Python 扩展、扫描仓库的 Git 集成、在文件夹打开时触发的任务运行器、在一轮结束时运行命令的钩子引擎，以及与此同时在一旁持有一个特权本地套接字的 Docker Desktop。

Pillar 本人对这一模式的总结只有一句话：“如果智能体能够写入系统未来的输入，那它从一开始就从未被沙箱隔离过。”每条链中的触发点都是提示注入——一条埋藏在 README、issue、依赖项或 diff 中的指令——而智能体并不需要将其识别为攻击。Pillar 用直接指令拍摄了每条链，因为这样更容易复现，并表示当智能体在日常工作中遇到同样的步骤时，这些步骤依然奏效。

暴露在风险中的，正是那些打开并非自己编写的代码仓库的人。Pillar 的论述是：开发者端点把源代码、SSH 密钥、云令牌、浏览器会话、包发布权限和生产访问权限集中到一处，而编码代理按设计恰恰会在这一处处理不受信任的输入。这些攻击链都不需要恶意软件或被攻陷的工具链；它们只需要一个代理被允许创建的文件，以及一个愿意信任该文件的主机组件。

四款产品中的七条链

Pillar 的概览列出了七项发现。其中三项完全位于 Cursor 中，两项位于 Antigravity，一项位于 Codex CLI，而第七项——Docker 套接字——在 Cursor、Codex CLI 和 Gemini CLI 中被以完全相同的方式报告，在此只计一次。机制各不相同；交接却并无二致。

• Cursor，兼容 Claude 的钩子。一个工作区文件（位于 .claude/settings.local.json）注册了一个 Stop 钩子，并且当智能体的回合结束时，Cursor 的钩子引擎在用户自己的上下文中执行了所配置的命令，且最终命令没有单独的审批。Cursor 分配了 CVE-2026-48124，并发布了公告 GHSA-pc9j-3qc2-95wv：高危，CVSS 4.0 基础评分为 8.5，影响 3.0.0 之前的 Cursor Desktop，并在 3.0.0 中修复。该 CVE 记录由 GitHub 作为 CNA 于 2026 年 6 月 15 日发布，比 Pillar 的系列早五周。

• Cursor，virtualenv 解释器。该代理将虚拟环境的 bin/python替换为一个包装脚本。Cursor 捆绑的 Python 扩展在未沙箱化的扩展宿主中执行解释器发现，扫描工作区根目录下两层，并根据文件签名而非文件夹名称进行匹配，因此一旦发现被触发，包装脚本就会运行——无论是在打开工作区、重新加载窗口，还是出现新环境时。两个文件就足够了：一个可执行的 bin/python和一个空的 pyvenv.cfg，放在任意名称的目录中。Pillar 记录了来自名为 data_cache 和 build_output的文件夹的执行，日期为 2026 年 2 月 16 日。CVE-2026-73217，高危，CVSS 4.0 评分 7.7，影响 3.1.2 之前的版本，并已在 3.1.2 中修复。

• Cursor：.git 之外的 Git 元数据。Cursor 的路径规则保护了名为 .git 的目录。Git 本身并不要求该名称：git init --separate-git-dir=.git-alt 会把元数据放到别处，而该目录中的 core.fsmonitor 值可以让 Git 指向一个可执行辅助程序。沙箱中的代理创建了该仓库和配置；随后 Cursor 的 Git 扩展自动检测到新仓库，并运行了一次常规的 git status，该命令在沙箱外执行了辅助程序，且没有审批提示。已在 3.0.0 中修复，发布时 CVE 仍在等待分配。

• Docker 套接字，现身于三款产品中。 在开启沙箱并授予网络访问权限的情况下，智能体可以运行 docker CLI、读取 Docker Desktop 的套接字、使用 curl 将 Alpine rootfs tar 包拉取到工作区，再用 docker import 导入它，从而让镜像仓库限制从未生效，并启动一个特权容器，以绑定挂载方式挂载沙箱本就允许访问的目录。从该容器内部，mount -t virtiofs virtiofs0 以读写方式暴露了用户的整个主目录——SSH 密钥、凭据、浏览器数据——而追加到 ~/.zshrc 的一行内容使载荷得以持久化。针对该攻击链，Cursor 的公告为 GHSA-v4xv-rqh3-w9mc、CVE-2026-73218，高危，CVSS 4.0 评分为 7.7，影响 3.0.0 之前的 Cursor。该公告的已修复版本字段显示为“None”；Pillar 报告称，Cursor 已发布修复，且该问题在下一个构建版本中不再复现。

• Codex CLI，安全命令白名单。 git show位于 Codex CLI 的默认白名单中；白名单成员会同时跳过沙箱和用户批准，理论依据是无论参数为何，它们都不会造成危害。 git show接受--output，它会写入任意路径，并且 --format，它控制内容。一次精心构造的调用将一条 diff.external 条目写入 .git/config；下一次 git diff——同样位于白名单中——以用户权限运行了攻击者的程序。Pillar 于 2026 年 1 月 7 日报告了此事，OpenAI 确认了 8.6 的 CVSS 评分，修复随 Codex CLI v0.95.0 于 2026 年 2 月 4 日发布，并于 2 月 17 日支付了赏金。该系列报道发布时，尚未发布 CVE。

• Antigravity：Seatbelt 拒绝列表。 Antigravity 的 macOS 沙盒配置文件（build 1.15.8）一开始就采用 (allow default)，并减去作者记得要拒绝的内容，因此该配置文件从未阻止文件系统挂载。一个 devfs 挂载无法携带 Launch Services 检查的来源扩展属性，因此在其上组装的应用包通过了检查；在 BASH_ENV通过该包的 Info.plist设置，并将指向 bash的符号链接作为可执行文件的情况下，open将该包交给了 launchd，后者在沙盒之外启动了 shell。Pillar 指出，该技术复用了 CVE-2023-32364——一个 Apple 于 2023 年修复的 macOS 问题——并且该修复在从未拒绝该挂载的默认允许配置下无关紧要。该攻击链需要关闭安全模式、开启终端沙盒，并将命令自动执行设置为“始终继续”。

• Antigravity、VS Code 任务。Antigravity 的写入工具拒绝访问 .git以及 .vscode 下的一组敏感名称，但 tasks.json 不在该列表中。一个带有 "runOn": "folderOpen" 的任务，再加上一个 settings.json，它已把 task.allowAutomaticTasks 开启；当用户下次重新打开项目时，该任务通过 VS Code 自身的任务运行器执行了——在重启之后，没有任何提示，且在安全模式之外。Pillar 的概念验证中注入的指令以要求用户重启编辑器结尾，而这几乎是编辑器能提出的最不引起怀疑的请求。

计数正是记录与其来源产生分歧的地方。该档案将这一发现标为跨四个编码代理的六次沙箱逃逸；Pillar 的概览列出了七项发现，而其网站如今刊有七篇逐日文章，其中包括 virtualenv 攻击链——尽管第三天的文章已经发布，该概览中对应行仍写着“文章即将推出”。上文描述的每条攻击链都出现在 Pillar 自己的表格中，而两份文档均未解释这一计数差异。

Codex 链：git show 曾经在安全列表上

Codex 的这项发现最清晰地说明了 Pillar 所称的“安全命令允许列表信任名称而非调用方式”这一失效模式。在 Codex CLI 中，允许列表上的命令会绕过沙箱并跳过审批提示；该列表是对子命令进行的 Rust match，允许以下命令：git branch、git status、git log、git diff和git show。这个 match 中没有任何内容会检查后面的标志。git show --format='[diff]%nexternal = bash -c ...' --no-patch --output=./.git/config HEAD因此同时通过了每一道确定性控制：允许列表放行了它，沙箱从未看到它，危险命令检测只查找 git reset和git rm，而 Git 在内部解析其余部分，没有任何可供检查的 shell 元字符。

Pillar 对该漏洞链的披露耗时超过六个月。报告于 2026 年 1 月 7 日通过 Bugcrowd 提交；Bugcrowd 的分诊团队无法复现，因为模型拒绝了注入的指令，而 Pillar 不得不论证，拒绝是概率性的，而不是一种控制手段——一个十次中有九次拒绝的模型，在第十次尝试时背后仍然没有任何保障。该报告于 1 月 15 日升级至 OpenAI，于 1 月 22 日被分诊为 P2，于 1 月 29 日评分为 8.6，于 2 月 4 日在 v0.95.0 中修复，并于 2 月 17 日支付赏金。公开披露于 7 月 20 日进行，并连同该系列一起发布。BleepingComputer 的 Ax Sharma 同日报道称，OpenAI 已支付一笔高严重度赏金，而一个 CVE 仍待定。

三家供应商以三种方式解读同一条链

Docker socket 链被以完全相同的方式发送给 Cursor、OpenAI 和 Google，而三者答案的分歧方式比任何单一补丁都更有信息量。Cursor 对其进行了分类处置，同意该 socket 应从沙箱外部运行，发布了修复，并将严重性定为高。OpenAI 同意该行为并非有意为之——Pillar 引用该评审称其接受智能体可被驱使进入破坏工作区边界的路径——随后将其范围缩小为配置和环境依赖，支付了报告费用，将其标记为信息性并拒绝授予 CVE，理由是 Unix socket 访问由网络代理中介，除非活动配置文件中明确允许某个 socket，否则会被拒绝。Gemini CLI 团队采取了最简短的立场：同一条链有效，相关风险已在其文档中明确说明。

谷歌对两个 Antigravity 发现再次给出了不同性质的答复。据 Pillar 称，谷歌将两者都归类为“其他有效的安全漏洞”，并作了降级处理，判定它们难以利用，因为它们需要社会工程手段，或者需要用户信任一个带有间接提示注入的代码仓库。Pillar 还引用了谷歌的反馈，称其中一份报告“质量极为出色”。这里的分歧在于前提条件，而非机制：谷歌并不否认这些攻击链确实奏效，Pillar 也不否认它们需要一条恶意指令才能触达智能体。

什么是已确立的，什么不是

• 已确认。这些利用链由 Pillar 复现，并随概念验证视频一同发布；厂商自己的记录也证实了那些获得标识符的漏洞。三个 Cursor 漏洞均带有由 GitHub 以 CNA 身份发布的 CVE——CVE-2026-48124（2026 年 6 月 15 日）、CVE-2026-73217 和 CVE-2026-73218（2026 年 8 月 11 日）——且每份公告文本都描述了 Pillar 所演示的同一机制，包括由工作区写入的 hook、被替换的 virtualenv 解释器以及特权 virtiofs0 挂载。Codex CLI 的修复已在 Pillar 的时间线中标注版本，并得到 BleepingComputer 同日报道的佐证。该档案将此记录评为高严重性，置信度为 A，而三份 CNA 记录和 BleepingComputer 的报道均与此一致。

• 已确认。未发现野外利用。Pillar 的系列文章、BleepingComputer 7 月 20 日的报道，以及本文查阅的 CVE 记录中，均未描述这些漏洞曾被用于攻击任何人。存档记录将 real_harm 标记为 false，这与上述来源一致。

• 单一信源。这些分步链路依据的是 Pillar 自己撰写的文章和视频。没有任何厂商发布过独立复现，而且 Bugcrowd 对 Codex 链的首次尝试也未能复现。厂商的确认可以证实这些问题确实存在，并且修复已经发布；但这些确认并不能独立验证 Pillar 叙述中的每一个步骤，因此本文全篇都将相关机制归因于 Pillar。

• 存在争议，但事实本身并无分歧。 Antigravity 的发现是否应获得 CVE 级别的处理。Google 将其降级并给出了理由；Pillar 记录了这次降级，而未对此提出异议。双方都不否认这些攻击链确实有效。

• 尚未确定。针对 Gemini CLI 攻击链的任何修复。Google 的立场是相关风险已有记录；在已审查的来源中，未出现任何 Gemini CLI 安全公告、补丁说明或修复版本。同样，Antigravity 所发现的问题也没有修复版本：据 Pillar 记录，Google 的回应只是一项分类定性，而非可供升级迁移的发布版本。

• 尚未确定。 针对 Docker 链、可供所有人引用的已修补版本。Cursor 针对 CVE-2026-73218 的公告未列出任何此类版本，其受影响范围是 3.0.0 之前的所有版本；Pillar 报告称复现在下一次构建时停止。这两项陈述相容但并不相同，只有 Cursor 能调和它们。

发生了什么变化，以及这项研究要求买家改变什么

具体来说：Cursor 用户需要 3.0.0 才能应对该 hook、Git 目录和 Docker 链，而 virtualenv 链则需要 3.1.2；这比该归档摘要中针对整个系列所列的版本更晚。Codex CLI 用户需要 v0.95.0，该版本自 2026 年 2 月 4 日起可用。Cursor 针对 CVE-2026-73217 的公告明确指出，发现过程会在沙箱之外执行由工作区控制的解释器，并且较早的受影响范围是 3.1.2 以下的所有版本。在已审查的材料中，Antigravity 和 Gemini CLI 用户没有可迁移到的版本。

Pillar 的建议是结构性的，而不是一份禁用文件名清单：凡是使用沙箱的地方，都从默认拒绝开始；将可能触发执行的工作区配置视为敏感；当 agent 创建或修改宿主机侧自动化时，要求显式批准；在与直接 agent 执行相同的策略下运行辅助程序执行；约束会执行由工作区控制的二进制文件的自动发现机制；在调用及其副作用的层面而非命令名称层面建模命令策略；限制对特权本地守护进程的访问；保留用户创建、仓库创建和 agent 创建的文件之间的来源关系；并监控信任交接，而不仅仅是监控 agent 进程。

该故障类别此前已被命名。Cymulate Research Labs于2026年4月7日发布了一篇文章，描述了其所谓的“基于配置的沙箱逃逸”（Configuration-Based Sandbox Escape）：该问题在Claude Code、Gemini CLI和Codex CLI中均有复现，并将Cursor和GitHub Copilot列入其影响范围——即沙箱被视为边界，而它能写入的主机侧配置才是真正的边界。BleepingComputer对Pillar系列漏洞的报道也建立了同样的关联。Pillar所补充的是广度——单周之内、来自三家厂商的四款产品，其底层都存在相同的交接机制。

这一系列文章留给任何运行这些工具的人的实际问题，比“它有没有沙箱？”更为具体。真正的问题是：允许智能体写入什么，哪个未沙箱化的组件信任该写入，以及当这两者相遇时是否有任何机制在监视。根据Pillar公布证据，三家供应商已经针对同一条完全相同的链路，以三种不同的方式回答了这个问题，而其中只有一种回答是补丁。