Cursor Codex Gemini CLI 全中招 AI Agent 沙箱逃逸的四种模式
Pillar Security 在 Cursor、Codex、Gemini CLI、Antigravity 中发现沙箱逃逸漏洞。Agent 不需要直接突破沙箱，只需要写一个文件让沙箱外的组件去执行。
安全公司 Pillar Security 发布了"沙箱逃逸周"系列研究，在 Cursor、Codex、Gemini CLI 和 Antigravity 四个主流 AI 编程工具中发现了沙箱逃逸和边界绕过漏洞。最关键的发现是：在几乎每个案例中，Agent 都不需要直接突破沙箱。它只需要写一个文件，让沙箱之外的受信任组件去执行那个文件。
四种可重复的失败模式
Pillar 识别出四种跨工具的通用失败模式：
1. 黑名单沙箱跟不上操作系统复杂度
传统做法是列出 Agent 不能执行的危险命令（denylist）。但操作系统的命令和参数组合太多，黑名单永远跟不上。Pillar 的案例展示了通过合法命令的非常规参数组合绕过黑名单的方法。
2. 工作区配置就是可执行代码
项目目录下的配置文件（.claude 目录下的 hook 配置、.git/config 等）会被工具自动读取和执行。Cursor 的案例（CVE-2026-48124）中，工作区内的 .claude hook 配置被转化为沙箱外的命令执行。攻击者只需要在仓库里放一个配置文件，打开仓库就触发。
3. 安全命令白名单只看命令名不看参数
Codex CLI 的案例中，命令白名单信任了一个"安全"的命令名，但没有检查命令参数和 Git 副作用。通过构造特定的参数组合，一个被白名单允许的命令可以触发任意代码执行（CVE 待分配，bounty 已获得 high severity 评级）。
4. 特权本地守护进程在沙箱边界之外
Codex、Cursor 和 Gemini CLI 共享的一个问题：本地有一个特权守护进程（比如 Docker socket），这个守护进程没有被沙箱限制。Agent 通过沙箱内的合法操作向这个守护进程发送请求，守护进程在沙箱外执行，等于绕过了整个沙箱。修复已发布（GHSA-v4xv-rqh3-w9mc）。
为什么传统沙箱设计不够
Pillar 的总结：AI 编程 Agent 改变了端点的威胁模型，但大多数沙箱设计还没有跟上。
传统沙箱假设只有用户会发起操作，所以重点防御的是外部攻击（网络入侵、恶意软件）。Agent 的场景不同：Agent 是一个受信任但可被操控的内部执行者。它可以被 prompt injection、恶意仓库内容或构造的上下文误导，然后利用它在沙箱内的合法权限来触发沙箱外的动作。
关键洞察是"间接执行"：Agent 不需要自己逃逸沙箱，只需要创建一个文件（hook 脚本、配置文件、任务定义），这个文件后续会被沙箱外的受信任工具（shell、Git、CI runner、Docker）拾起并执行。
已修复的漏洞
| 漏洞 | 工具 | 状态 |
|---|---|---|
| Docker socket 特权逃逸 | Codex, Cursor, Gemini CLI | 已修复 GHSA-v4xv-rqh3-w9mc |
| 白名单命令 RCE | Codex CLI | 已修复 v0.95.0 |
| Hook 配置逃逸 | Cursor | 已修复 v3.0.0, CVE-2026-48124 |
所有漏洞在论文发布前已修复。但 Pillar 的研究指出，这些修复是逐个补洞，底层的架构问题（沙箱设计没有考虑 Agent 作为内部威胁源）仍然存在。