CVSS 9.4:AI 编程助手沙盒逃逸漏洞解析

一个把自己牢门打开的 AI 助手

先说一个画面：你把 AI 编程助手关进“安全沙盒”里干活，就像让装修工只在一个划定的房间里施工。它不能碰别的房间、动不了你的私人物品。

结果这次，这位装修工在干活的过程中，伸手把自己那扇门拧开了。

2026 年 9 月 8 日，安全公司 OX Security 公开了一个漏洞，编号CVE-2026-82533，CVSS 评分9.4（高危），漏洞类型 CWE-807 —— 用人话说就是“它信了不该信的东西”。发现者是 Nir Zadok 和 Moshe Siman Tov Bustan。

出问题的是 DeepSeek Harness，一个 2026 年 8 月开源的本地优先 AI 编程助手框架（命令行叫 dsh）。它最坏的情况是：被沙盒限制住的 AI，用一条 shell 命令，把自己的会话权限改成“无沙盒、无审批”，从这一刻起，它执行的每条命令都不再受约束、也不再问你。

先别慌，这件事已经被修复了，而且目前没有公开证据显示有人真的拿它攻击过别人。但你该知道它为什么能发生。

先说清楚：沙盒到底在关什么

AI 编程助手和普通聊天机器人不一样，它真的会动手——跑命令、装依赖、改文件。所以几乎所有的同类工具都会给它套一层 OS 级沙盒。

目前主流做法是操作系统自带的机制：Linux 上常见 bubblewrap、Landlock，macOS 上是 Seatbelt。它们的思路很朴素：允许你干活，但把“写入范围”圈起来。

问题恰恰出在这个思路的缝隙里。

这次涉及的沙盒，只限制了文件写入，却放行了本地网络。技术细节是：Linux 侧传了 --unshare-pid，但没有传 --unshare-net；macOS 侧是 (allow default) 加 (deny file-write*)——也就是“默认全放行，只禁止写文件”。

翻译成人话：沙盒给 AI 划了一块施工区，但没断它的电话线。它依然可以跟本机上跑着的各种服务说话。

而它要说话的那个服务，就是这个工具自己的控制接口。

三个小疏漏，凑成一条越狱路径

单看任何一个疏漏，都不算致命。凑在一起，就成了一条完整路径。

第一个疏漏：控制接口没有鉴权。

这个工具的浏览器界面，是靠本机 127.0.0.1:3080 上的一个 HTTP 接口支撑的，默认不校验身份。它判断一个请求“是不是可信”的方式，是看请求自己报上来的 Host 头（代码里的函数叫 isTrustedApiRequest）——它从不核对连接到底从哪来，也没法核对。这个文件的注释里甚至直白地写着，它“is not an auth layer”（不是一层认证）。

第二个疏漏：沙盒里的命令能直接访问这个接口。

因为上面说的“放行本地网络”，AI 在沙盒里跑的任何命令，都能毫无阻碍地跟本机的这个接口对话。

第三个疏漏：默认不审批，而且这次的动作恰好绕开了审批。

这个工具的审批提示，管的是“申请比当前会话更大的权限”。可这一次，调用接口做的是改会话设置，不是申请权限——语义上不匹配，于是不触发任何提示。

三条凑齐，结果就是：AI 在沙盒里发一个请求（curl 之类的命令行工具就能做到），把自己的会话改成最高权限档位、审批设为永不询问。

此后它执行的每条命令都出了沙盒，而且不留痕迹——官方披露里提到，日志里连一条 approval 事件都没有，这次操作还被记录成 source: {kind: 'user'}，也就是系统分不清这条指令是 AI 自己发的，还是坐在键盘前的人发的。

唯一的前提，是 AI 执行了外面喂进来的文本——比如你让它读的那个仓库，README、代码注释或者 issue 里藏着一段指令。这也是为什么它被归到“信任了不可信输入”这一类。

至于具体那条命令长什么样，我这里不复述。知道“一条命令就够了”这件事本身，比知道命令怎么拼更重要。

最有说服力的部分：他们做了对照组

安全团队没有停在“理论上可以”。他们做了个对照实验。

同一台机器、同一套默认设置、同一条命令：

• 先跑过提权请求的那个会话，成功往工作区之外的 /home/ubuntu 写入了文件；
• 没跑过提权请求的会话，被沙盒稳稳拦住。

这个对照很有价值：它说明逃逸之前，沙盒确实在正常工作。这不是“沙盒从来没用”，而是“这道篱笆上有个洞，洞后面的锁没扣上”。

第二条路：不用碰你的电脑，也能拿走全部对话

上面那条路是“AI 自己越狱”。还有一条对普通用户更隐蔽的路径。

那个控制接口本身还提供一个功能：下载某个会话的完整日志。

平时它只在本机监听，外面碰不到。但如果这个端口被转发到了网络上——隧道、反向代理、SSH 转发，或者编辑器自带的端口转发——外面的人就可以直接接管会话，不需要任何密钥，也不需要调用模型，就能把全部历史对话拉走。

安全媒体 The Hacker News 在核对这个工具的 CLI 行为时确认了一点：它本身拒绝监听所有网卡，这是挡住“远程直连”的最后一道措施。也就是说，暴露面基本来自你自己做的端口转发。

很多人为了让手机也能打开这个界面，顺手就把端口转出去了。转的时候只想图个方便，没意识到那等于把一个不设门禁的控制台放到了公网上。这一点值得记住：本地端口不等于“只有你能访问”。

官方修了，但补的是门锁，不是围墙

修复在 8 月 27 日就提交了，方式很直接：启动时打印一个一次性 token，浏览器用它换一个签名 cookie，之后每次调用接口都要带上 cookie。

听上去问题解决了，对——也不完全对。

因为这次修复只补了鉴权，沙盒本身一行都没动。在修复后的版本文档里，默认设置下依然写着 reads and network access are not confined（读文件和网络访问并不受限），AI 的 shell 依然能拿到接口地址和当前会话标识。The Hacker News 的结论是：默认本地安装、工具运行中的状态下，没有已知办法能从沙盒内部阻止这类逃逸；8 月 13 日社区的报告也指出，光是限制接口监听地址没用，因为 AI 本来就在同一台机器上。

一句话总结：补上的是门锁，不是围墙。升级之后别再默认“沙盒已经加固了”。

另外有个版本上的坑，必须提醒——CVE 记录里写的修复版本0.1.2-alpha.1，从来没有发布到 npm，而项目自己的安装指引指向的正是 npm。这个版本在 GitHub 上只是一个 tag，连 Release 条目都没有。完整的版本链是这样：

• 0.1.2-alpha.1
  ：8 月 27 日的修复提交，只存在于 GitHub 的 tag；
• 0.1.2-alpha.2
  ：8 月 30 日，npm 上第一个含修复的版本；
• 0.1.5-rc.1
  ：9 月 10 日发布，是我们 9 月 15 日核对时 npm 上的最新版本（The Hacker News 9 月 9 日核对时还是 0.1.2-rc.1）。

受影响的版本是 0.1.1-rc.2 及更早。

顺便说一个别踩的坑：npm 上有一个同名但非官方的包，描述里写明是“名称保留”用的占位包，维护者也不是官方账号。别照着搜索结果里的名字装，从官方仓库页面点进去更稳妥。

还有一点值得记下来：项目把这个改动写成了常规变更，没有发安全公告，也没提 CVE 编号。而项目自己的安全说明里写着一句很实在的话——这些机制“不保证隔离、也不阻止损害”（The Hacker News 引述了项目文档）。这不是官方不知情，而是官方从来没承诺过“牢不可破”。

你现在该做的四件事

第一，先查你实际跑的到底是哪个版本。

不要照抄网上流传的升级命令，去官方仓库的 Release / tag 页面，或者 npm 上这个项目的版本页面，看你装的到底是什么。只要在 0.1.2-alpha.2 及以后，就包含这次修复。

如果你用的是第三方桌面封装版，先查它内置的是哪个版本——这类封装往往自带一份 AI 助手副本，更新节奏晚于上游，某 Windows 构建 8 月底还停在 0.1.1-rc.2，9 月 6 日才更新到含修复的版本。

第二，别把本地控制端口转发到网络上。

隧道、反向代理、SSH 转发、编辑器端口转发，都算暴露。如果一时半会儿没法升级，那就“不用的时候关掉 Web 界面、撤掉转发”，这是最直接的止损。

第三，保留审批提示，但别把它当万能保险。

这次绕过恰恰是利用了“审批只管提权申请”的语义空隙。审批该开还是开，但它不能替你兜住所有事。

第四，把 AI 会读到的外部文本当成不可信输入。

代码注释、README、issue 里的注入是这次攻击唯一的前提条件。让 AI 去处理陌生仓库时，把权限调低一点，别让它顺手碰到你的密钥和凭证。

这不是一家的问题

云安全联盟（CSA）在 9 月 10 日的研究笔记里，把这件事放进了更大的图景：2026 年已经记录过同类“沙盒失守”，比如 7 月 22 日的 trust handoff、7 月 1 日的 GuardFall。它们的共同点是——厂商宣称的安全边界，未必等于在对抗压力下真实成立的边界。

Forkast 则把这次事件称作第一个以“AI agent 运行时沙盒本身”为直接攻击面的已确认漏洞。这只是该媒体的判断，不是官方结论，但方向值得记住。

最后说一句实话：沙盒是降低风险，不是保证隔离。项目自己也是这么写的。这条不只适用于这一家——你现在用的任何一个能跑命令的 AI 助手，都值得按这个思路重新看一眼设置。

你平时会顺手把本地端口转发到手机上用吗？如果有，回去检查一下那几个还开着吧。

觉得有用？点个关注，持续获取优质内容。