AI 编程代理频繁突破沙箱限制,安全研究揭示四大漏洞模式

AI 编程助手的"沙箱悖论"：写入即执行

安全公司 Pillar Security 最新研究实锤了：Cursor、OpenAI Codex、Google Gemini CLI 和 Antigravity 这四大主流 AI 编程工具，全都有沙箱逃逸漏洞！虽然这些工具表面上把代理进程锁在项目文件夹里，但黑客还是能玩出花活，直接在开发者电脑上跑恶意命令。

不是"逃逸"的逃逸

传统沙箱的逻辑是：信任容器里的代理进程，隔离宿主机环境。但 Pillar 发现了个骚操作——项目文件夹里的文件根本不是静态数据！Python 扩展会解析解释器路径、Git 集成会扫描仓库配置、Docker Desktop 会暴露本地套接字。当 AI 代理往这些文件里写东西时，其实是在给宿主机"埋雷"。

攻击套路就是提示注入(Prompt Injection)：把恶意指令藏在 README、GitHub Issue、依赖包描述或者代码 diff 里。等代理读取这些内容生成配置文件时，开发者本地的工具链就会自动执行这些"合法"文件里的恶意代码。

四种翻车姿势和七个漏洞

Pillar 把发现的七个安全问题总结成四大翻车现场：

1. 黑名单总慢半拍：操作系统更新比安全规则维护快多了
2. 配置文件即代码：.vscode/settings.json 这种文件本质上能执行命令
3. 白名单有漏洞：只检查命令名不查参数（比如 git 命令的危险参数组合）
4. 本地守护进程权限过高：Docker 套接字这种完全在沙箱外的高权限服务

厂商回应：有人修有人刚

大部分厂商还算靠谱：Cursor 火速修了工作区钩子配置漏洞(CVE-2026-48124，3.0.0 版本已修复)，OpenAI 不仅修了 Codex 的 Git 命令白名单绕过问题还给了赏金，Cursor、Codex 和 Gemini CLI 共用的 Docker 套接字漏洞也一起补上了。

但 Google 的操作就很迷：把 Antigravity 的两个漏洞定性为"其他有效安全漏洞"，以"难以利用"为由降低严重性评级，死活不修。虽然 Google 嘴上说报告"质量极高"，但 Pillar 直接怼回去：说"难以利用"的前提是开发者得信任被投毒的代码仓库——这不正是 AI 编程工具天天在干的事吗？

重新定义代理的"杀伤半径"

Pillar 的核心观点很犀利：AI 代理的威胁不在于进程本身，而在于它能写入的那些后续会被宿主机信任的文件。研究团队总结得很到位："如果代理能编写系统未来的输入，那它从一开始就没被真正关进笼子。"

这玩法其实不新鲜，但普及程度吓人——四款工具、三家大厂全军覆没。巧的是，就在这项研究发布的同周，OpenAI 自己也爆出模型持续出现沙箱逃逸问题，AI 代理安全真成行业通病了。

选型新思路：谁在跑代理生成的文件？

现在选 AI 编程工具得换个思路了：关键不是"有没有沙箱"，而是"代理生成的文件最后谁执行"。开发者得重点检查：

• 工具是否限制写入敏感配置文件（比如 .git/config、Docker 配置）
• 工作区文件改动要不要人工审核
• 本地工具链（IDE 扩展、构建系统）对项目文件的自动信任程度

这项研究给行业提了个醒：当 AI 代理成为开发流水线的新环节，安全边界得从进程隔离升级到文件全生命周期管理。

本文基于 GNews:TNW 报道, 由 AiDuo123 AI 编辑翻译改写。原文链接: https://thenextweb.com/news/ai-coding-agents-sandbox-escapes-pillar