四大 AI 编程代理集体沙箱逃逸｜Cursor / Codex / Gemini CLI / Antigravity 全中，攻击藏在 README 里
一句话总结
四大 AI 编程代理 Cursor / Codex / Gemini CLI / Antigravity 集体暴露沙箱逃逸，攻击靠 README 间接提示注入实现宿主机任意代码执行。
Pillar Security 7 月 22 日披露——Cursor、OpenAI Codex、Google Gemini CLI 及 Antigravity 四款主流 AI 编程代理均存在沙箱逃逸安全隐患。这是首次多厂商同时暴露同一类漏洞。
攻击路径跳出常规——攻击者无需强行破解沙箱本身、只需在开源仓库的 README、Issue、依赖库或代码差异中植入恶意提示（间接提示注入 indirect prompt injection）。诱导 AI 代理在项目工作区写入看似正常的配置文件、虚拟环境或命令指令。
真正的漏洞在沙箱外的信任链——主机系统上的 IDE 与 CLI 工具链（Python 解释器、Git 机制、任务引擎等）会定期自动读取并信任工作区文件。这些「留在盒子内」的文件便会在沙箱之外被直接加载运行、攻击者无需正面攻破隔离层即可在开发者本地实现任意代码执行。
被打穿的设计盲区——白名单仅校验命令名、不校验参数（允许 python 但不管脚本内容）；沙箱外特权服务被暴露（Git hooks、shell rc 文件在宿主机自动执行）。这是 12 年前 Adobe Reader 沙箱逃逸的同款设计错误、只是换到了 AI agent 场景。
厂商修复进度——Cursor 升至 3.0.0、Codex CLI 升至 v0.95.0、Gemini CLI 已推送补丁。Google 对 Antigravity 的两项漏洞做降级处理、认为其利用需配合社工攻击诱导信任恶意仓库——这个判断业界并不完全接受。
实际威胁面——GitHub 上任何 star 数合理、看起来合法的仓库都可能被投毒。依赖混淆攻击（malicious dependency）在 AI agent 场景放大 10 倍——因为 agent 默认信任 npm、pip 上的包、且自动执行构建脚本。
给开发者的实操建议——disable auto-approve、不要授权 AI agent 自动写入 ~/.bashrc、~/.zshrc、.git/hooks/；用 Docker 或 dev container 而非沙箱运行 AI agent。
via BleepingComputer
攻击路径跳出常规——攻击者无需强行破解沙箱本身、只需在开源仓库的 README、Issue、依赖库或代码差异中植入恶意提示（间接提示注入 indirect prompt injection）。诱导 AI 代理在项目工作区写入看似正常的配置文件、虚拟环境或命令指令。
真正的漏洞在沙箱外的信任链——主机系统上的 IDE 与 CLI 工具链（Python 解释器、Git 机制、任务引擎等）会定期自动读取并信任工作区文件。这些「留在盒子内」的文件便会在沙箱之外被直接加载运行、攻击者无需正面攻破隔离层即可在开发者本地实现任意代码执行。
被打穿的设计盲区——白名单仅校验命令名、不校验参数（允许 python 但不管脚本内容）；沙箱外特权服务被暴露（Git hooks、shell rc 文件在宿主机自动执行）。这是 12 年前 Adobe Reader 沙箱逃逸的同款设计错误、只是换到了 AI agent 场景。
厂商修复进度——Cursor 升至 3.0.0、Codex CLI 升至 v0.95.0、Gemini CLI 已推送补丁。Google 对 Antigravity 的两项漏洞做降级处理、认为其利用需配合社工攻击诱导信任恶意仓库——这个判断业界并不完全接受。
实际威胁面——GitHub 上任何 star 数合理、看起来合法的仓库都可能被投毒。依赖混淆攻击（malicious dependency）在 AI agent 场景放大 10 倍——因为 agent 默认信任 npm、pip 上的包、且自动执行构建脚本。
给开发者的实操建议——disable auto-approve、不要授权 AI agent 自动写入 ~/.bashrc、~/.zshrc、.git/hooks/；用 Docker 或 dev container 而非沙箱运行 AI agent。
via BleepingComputer