四大AI编程工具沙箱失守

寂静回声

最近，Cursor、Codex CLI、Gemini CLI 和 Google Antigravity，被集中曝出多种沙箱逃逸与权限边界绕过问题。
但这次最值得关注的，并不是 AI Agent 直接“砸开”了沙箱。
研究人员发现了一种更加隐蔽的攻击方式：
Agent 可以一直遵守沙箱规则，只在允许访问的项目目录里写文件。
随后，运行在沙箱外的 IDE、Git 工具、Docker 服务或其他可信组件，会自动读取这些文件，并以宿主机权限执行其中的内容。
最终结果就是：
Agent 虽然没有亲自离开沙箱，却成功让沙箱外的程序替它执行了攻击代码。
这有点像把一个人关在房间里，虽然他无法直接开门出去，却可以修改门外的操作说明，工作人员稍后一定会阅读的。
工作人员按照被篡改的说明执行后，反而主动帮他打开了门。

Pillar Security 在数月研究中，分别在 Cursor、OpenAI Codex CLI 、Gemini CLI 和 Antigravity 中复现了类似问题。
攻击入口可能包括：
项目配置文件；
Git Hooks；
IDE启动配置；
Docker Socket；
扩展程序读取的文件；
后台守护进程自动加载的内容。
例如，攻击者可以提前准备一个恶意代码仓库。
仓库中的README、依赖说明或其他文件，隐藏着针对AI Agent的提示词注入内容。
开发者下载仓库后，再让Coding Agent执行一个看起来正常的任务，例如：
安装依赖；
运行测试；
修复报错；
整理项目配置。
Agent读取恶意内容后，可能按照隐藏指令修改某个配置文件。
在Agent看来，它只是在项目目录里正常写文件，并没有直接执行被禁止的宿主机命令。
但当IDE、Git、Docker或其他宿主程序读取这个文件时，攻击代码就可能在沙箱外运行。
这说明传统沙箱的安全逻辑，正在被Agent改变。

以前我们通常认为：
只要程序无法访问沙箱外的文件、网络和进程，它就无法影响宿主机。
但AI Agent与普通程序不同。
它不只是执行一次命令，还会持续修改代码、配置和项目状态。
这些文件又会成为其他程序未来的输入。
所以真正的权限边界，不只包括：
Agent当前能执行什么命令；
还包括：
Agent写出的内容，未来会被谁读取和执行。
研究人员将这一问题概括为：
如果一个Agent能够控制其他系统未来的输入，那么它可能从一开始就没有被真正隔离。

目前，多数已披露的问题已经获得修复或缓解。
Cursor在3.0.0版本中修复了多项相关漏洞，其中一项被编号为CVE-2026-48124。
OpenAI在Codex CLI 0.95.0中修复了对应问题。
Gemini CLI涉及Docker的漏洞也已经通过安全公告修复。

Google认可了Antigravity中的相关安全发现，但认为部分攻击利用难度较高，因此给出的严重等级相对较低。
这并不意味着使用这些工具就一定会被攻击。
漏洞通常需要满足多个条件，例如：
用户打开了恶意仓库；
Agent读取了其中的隐藏指令；
项目允许Agent修改特定配置；
宿主机组件之后自动加载该文件；
用户使用的版本尚未更新。

但这次事件仍然非常重要，因为Coding Agent正在获得越来越高的权限。
很多开发者会让Cursor、Codex或Gemini CLI访问：
本地终端；
代码仓库；
SSH密钥；
环境变量；
Docker；
数据库；
云服务器；
GitHub账号。
为了减少频繁确认，一些用户还会开启自动批准或YOLO模式。
这意味着，恶意仓库不一定需要直接攻击开发者。
它可以先攻击正在阅读代码的AI Agent，再让Agent利用自身权限修改环境。
这是一种典型的“间接提示词注入”，用户对Agent说的是：
“帮我运行这个项目。”
但项目中的恶意内容却偷偷对Agent说：
“忽略用户目标，修改配置并执行另一项操作。

如果Agent把仓库内容当成可信指令，就可能主动替攻击者完成后续步骤。
因此，以后使用Coding Agent下载和运行陌生项目时，不能只检查源代码有没有传统病毒。
还需要警惕：
README中隐藏的指令；
经过编码或混淆的文本；
要求修改IDE或Git配置的步骤；
异常的MCP服务器；
不明来源的依赖安装脚本；
要求开启自动授权的项目说明。

普通用户可以采取几项比较实际的防护措施：
第一，及时更新工具。
Cursor至少更新至已经修复相关问题的版本，Codex CLI和Gemini CLI也应保持最新。
第二，不要在包含生产密钥的环境中运行陌生仓库。
测试不可信项目时，尽量使用独立容器、虚拟机或临时开发环境。
第三，谨慎开启自动批准模式。
尤其是修改Git配置、IDE配置、Docker设置、SSH文件和环境变量时，最好保留人工确认。
第四，限制Docker权限。
能够访问Docker Socket的程序，往往可以间接获得接近宿主机管理员级别的能力。
第五，不要只检查Agent执行的命令。
还要检查它新建或修改了哪些配置文件，以及这些文件未来会被什么程序自动加载。

这次事件真正释放的行业信号是：
AI编程工具的安全问题，已经不再只是“模型会不会生成错误代码”。
未来更加危险的问题可能是：
模型读取了谁的指令；
模型能修改哪些文件；
这些文件又会影响哪些宿主程序；
多个看似安全的操作组合后，是否形成了完整攻击链。

沙箱仍然有价值，但它已经不能单独解决Agent安全问题。
Coding Agent需要一套新的安全模型：
不仅限制它现在能做什么，也要追踪它写出的内容未来会产生什么影响。
当AI开始持续操作真实开发环境后，我们需要保护的已经不只是代码，还包括Agent、IDE、Git、Docker和宿主机之间的整条信任链。