Cursor、OpenAI Codex CLI、Google Gemini CLI、Antigravity——四款 AI 编码 agent 产品，七条绕过沙箱的攻击路径，一条共通的核心缺陷。
2026 年 7 月 20 日，Pillar Security 的安全研究员 Eilon Cohen、Dan Lisichkin 和 Ariel Fogel 发布了名为「The Week of Sandbox Escapes」的研究系列。他们花了几个月时间逐一测试这四款产品的沙箱边界。结论是：这些沙箱的边界画错了地方。
没有攻击沙箱本身
这三名研究员没有试图打破沙箱的围墙。他们问了一个更刁钻的问题：沙箱的围墙立在正确的位置上了吗？
答案是否定的。在每一种场景中，agent 都遵守了规则。它没有越狱进程边界，没有突破文件系统限制，没有调用被禁用的系统调用。它只是写了一文件。一个运行在沙箱之外、受信任的宿主进程读了那个文件，信任了它，然后执行了其中的内容。逃逸发生在 agent 从未触碰边界的情况下。
Pillar 的团队把发现总结为一句话：agent 的爆炸半径是 agent 能写入、且宿主后续会信任的一切——不是 agent 进程本身。
这句话是整个研究的核心，也是为什么打个补丁并不能了事。
四个失败模式
Pillar 将七条漏洞归纳为四个可重复的失败模式：
- 黑名单式沙箱：以「默认允许」开头的沙箱策略总是漏掉某个危险操作。macOS Seatbelt 的 denylist 风格让 Antigravity 的第一条漏洞成为可能。
- 工作区配置即代码：Agent 写入了一个它「有权」写入的文件。问题是那个文件是
.vscode/tasks.json、.git/config、.claude钩子配置——宿主工具会把它当成可执行配置来解析。 - 命令名不等于安全性：Codex CLI 的安全命令白名单信任了
git show这个命令名，却没有检查传入的参数可以做什么。 - 沙箱外的特权守护进程：Docker 套接字是本地系统上一个具备完整主机权限的执行入口。Agent 不能直接逃逸，但可以向 Docker 守护进程发请求，后者帮忙逃了。
Docker 套接字：一个 CVSS 覆盖三个产品
最平淡无奇、也最广泛的问题，是 Docker 套接字。
Codex CLI、Cursor 和 Gemini CLI 这三款产品，都允许 agent 从沙箱内部访问本地的 Docker 套接字。Docker 守护进程运行在沙箱之外，以宿主级别权限运行。Agent 不能自己执行任意命令，但它可以告诉 Docker 启动一个挂载了宿主文件系统的容器。只要几行代码，agent 就有了宿主级别的读写能力。
这个漏洞被追踪为 GHSA-v4xv-rqh3-w9mc。一条安全通告覆盖了三个不同的产品。
Pillar 指出，开发者终端上充满了这类「第二执行环境」：Docker Desktop、包管理器、云 CLI、语言服务器、构建守护进程、本地数据库、模拟器。任何一个是 agent 可达的，都成了信任桥接点。
Cursor：三条路径，同一种根源
在所有受测产品中，Cursor 暴露的问题最多——三条不同的逃逸路径。
第一条：虚拟环境劫持（GHSA-p9g2-cr55-cw9c）。 Agent 修改了 Python 虚拟环境中的解释器二进制文件。Cursor 的 Python 扩展（运行在沙箱之外、没有权限限制）在执行自动发现时会调用这个解释器。Agent 不需要突破任何限制，它只是把文件改成了宿主进程后来执行的东西。
第二条：非标准 .git 目录（等待 CVE）。 很多沙箱通过路径匹配来阻止 agent 修改 .git 元数据。但这个保护依赖于一个假设：Git 目录一定叫 .git。研究员让 agent 创建了一个名称不同的 Git 目录，绕过了路径规则，然后利用 Git 的 fsmonitor 功能让宿主 Git 进程执行了来自工作区的脚本。
第三条：.claude 钩子配置（CVE-2026-48124，GHSA-pc9j-3qc2-95wv）。 Agent 向工作区写入了一个 Claude Code 钩子配置文件。Cursor 的钩子执行引擎以完全无沙箱的方式运行了这个配置。这个漏洞被评为高危，已在 Cursor 3.0.0 中修复。
三条路径的共性是：agent 没有攻击沙箱，而是攻击了宿主对工作区文件的信任。
Codex CLI：白名单不等于安全
OpenAI Codex CLI 的问题出在安全命令白名单上。
Codex 维护了一个允许 agent 执行的命令列表，其中包含了 git show。从名字上看，这是一个只读操作。但 Git 的参数解析远比表面复杂：git show 可以接受 --config 参数加载任意配置文件，可以触发 Git 钩子，可以写出文件，可以调用外部工具。
研究员将这项漏洞命名为 GitPwned。白名单检查的是命令名，而不是实际执行的参数组合和副作用。
Pillar 总结了一个关键问题：安全策略的检查对象应该是「这次调用做了什么」，而不是「这次调用了谁」。这个漏洞已在 Codex CLI v0.95.0 中修复，研究员获得了高危漏洞奖金。
Antigravity：Google 的争议性降级
Antigravity 是 Google 的 AI agent 框架。研究员发现了两个沙箱绕过。
第一个：macOS Seatbelt 黑名单。 Antigravity 使用 macOS 的 Seatbelt 机制进行沙箱隔离。但这个配置是黑名单（denylist）风格——只阻止已知的危险操作，其余的全部放行。macOS 系统庞大且复杂，要列出所有危险操作几乎不可能。研究员找到了 Seatbelt 未覆盖的执行路径，完成了逃逸。
第二个：.vscode 定时炸弹。 Antigravity 有一个名为 Secure Mode 的保护模式。但研究员发现，agent 可以写入 .vscode/tasks.json 文件——这是 VSCode 的任务配置文件。当用户在 VSCode 中打开项目时，编辑器会自动执行任务配置中定义的命令，完全绕过 Antigravity 的沙箱。
Google 对这两个漏洞的回应值得关注。他们将两者都归类为「Normal Google Applications」，并在确定难以利用后降低了评级。理由是：利用这些漏洞需要社会工程或用户信任了包含间接提示注入的代码仓库。
Google 称这批报告「质量极高」。但降级决定本身在安全社区引发了讨论。传统的 CVSS 评分体系并不适合 AI agent 特有的信任模型——对于 agent 而言，「社会工程」就是一句写在 README 里的句子、一段依赖文档中的文字、一条 issue 评论。读取不可信文本是 agent 的日常工作。
Claude Code 的前车之鉴
这不是 AI 编码 agent 第一次在沙箱问题上翻车。
此前的 CVE-2026-39861 涉及 Anthropic 的 Claude Code。漏洞出在符号链接（symlink）处理上：Claude Code 的沙箱没有阻止 agent 进程创建工作区外指向敏感路径的符号链接。当沙箱外的一个无限制进程后续向这条路径写入数据时，它跟随着符号链接，写到了攻击者指定的目标位置。这个漏洞在 Claude Code 2.1.64 中修复。
将 Claude Code 的 CVE-2026-39861 和 Pillar 的七个发现放在一起看，模式更加清晰：沙箱边界和宿主工具之间的信任关系没有被纳入威胁模型。
沙箱的边界不是进程，是工作区
这些产品的共同推销点是把沙箱作为安全控制的核心，让客户相信「agent 不能伤害你的系统」。Pillar 的研究表明，这个承诺只覆盖了 agent 进程本身，从来没有覆盖过工作区。
但问题在于，工作区才是真正的攻击面。工作区中的文件被一长串工具读取——Python 扩展、Git 守护进程、pre-commit 钩子、依赖安装器、CI 运行器——这些工具的设计早于 AI agent 的出现，它们默认信任文件中的内容。
一条来自 Lobsters 社区的评论（用户 emk）一针见血：「任何基于『让用户批准或拒绝』的机制都是灾难。OS 级别的沙箱很好，但如果你允许 agent 对 $HOME/Documents/Taxes/ 拥有只读权限也不行——你需要隐藏工作目录之外的一切。」
另一位用户 natfu 指出了现实中的矛盾：「agent 拥有更多权限时更有用。如果你把它们锁死，不让它们看到网络、文件和有用的 CLI 工具，那它们几乎没用。系统本身就在把你拉向不良安全实践。」
emk 的回复提供了一个思路：「Linux 确实支持这种沙箱化，但需要专业知识来配置最小权限。我给 agent 自己的用户账户，让操作系统像对待共享 Unix 主机上的非可信用户一样对待它。安全应该在环境中，而不是在工具上。」
为什么这不是打补丁能解决的问题
Cursor 已发布 3.0.0，Codex CLI 已发布 0.95.0，Gemini CLI 也修复了 Docker 套接字问题。单从补丁覆盖率看，这像是一个常规的安全事件。
但 Pillar 的研究清楚地表明，这是个系统性问题。
现代 IDE 和 CLI 充满了宿主端的自动化机制：Python 解释器发现、Git 仓库扫描、VSCode 任务运行器、钩子引擎、依赖安装器、Docker 套接字。这些机制信任工作区的内容，因为它们假设了工作区的内容来自人类开发者。当工作区的写入者变成一个 AI agent——一个可以读取不可信输入、遵循指示、反复执行、组合操作的进程时，这个信任假设就崩溃了。
Pillar 给出了一个实用的提问清单，供安全团队在评估 AI 编码工具时使用：
- agent 可以写入什么？
- 哪些宿主组件信任这些写入？
- agent 可以访问哪些本地守护进程？
- 哪些命令跳过了审批，为什么？
- 策略是在命令名层面执行，还是在参数和副作用层面？
- 产品能否区分用户创建、仓库创建和 agent 创建的文件？
- 当受信任的 helper 运行了 agent 写入的内容时，是否有遥测可以记录？
你可以做的事情
对于正在使用这些工具的团队，有几个可以立即采取的行动。
关闭 Docker 套接字。 没有 AI 编码 agent 需要访问 Docker 套接字，而这一条配置变更就关闭了覆盖三个产品的最大漏洞。
升级版本。 Cursor 3.0.0 和 Codex CLI 0.95.0 是修复版本。开发者工具按用户升级而非按集群升级，厂商发布补丁不代表你的工程师已经安装。
重新审视工作区的信任模型。 Agent 触碰过的分支到达 CI 时应当被视为不可信。在有人类审查 diff 之前，CI 流水线不应执行该分支提供的钩子、任务或解释器。
参考链接
- Pillar Security 原创研究《The Week of Sandbox Escapes》（含四家厂商的完整技术细节和 PoC）
- BleepingComputer 报道《Cursor, Codex, Gemini CLI, Antigravity hit by sandbox escapes》
- Lobsters 社区讨论帖（emk 和 natfu 关于 agent 安全和 Linux 沙箱的深入分析）
- Servola 博客分析《Four Coding Agents Escaped Without Breaking Out》
- Shield53 分析《AI Coding Agent Sandbox Escapes Signal a Systemic Trust Problem》
结语
本文的素材来自公开信息和社区讨论。如果你对这个话题有更深入的一手经验，欢迎指出文中的不足。
