DeepSeek Harness：可以自行关闭沙箱的受限智能体

这是什么？

2026 年 9 月 8 日，OX Research 的 Nir Zadok 与 Moshe Siman Tov Bustan 公开了他们的披露报告，涉及 DeepSeek Harness（dsh）中的一个缺陷。该工具是 DeepSeek 推出的开源本地优先框架，用于在开发者本机运行编码智能体。在出厂默认配置下，一个受沙箱限制的智能体仅需一条 shell 命令即可关闭自身沙箱，既不需要网络暴露，也不需要任何凭据。作为 CNA 的 VulnCheck 于同日发布记录，评分为 9.4。

该框架于 2026 年 8 月发布，数周内 GitHub 星标即突破 21.5 万。它提供一个由本地 HTTP API 支撑的浏览器界面，并在操作系统沙箱中执行智能体命令——视平台而定，使用 bubblewrap、Landlock 或 Seatbelt——其目的正是让处理不可信材料的智能体无法越出自己的工作区。

值得注意的并非沙箱存在漏洞，而是沙箱的控制平面本身就在沙箱之内。

工作原理

三个各自单独看都说得通的普通设计决定，组合出了一条逃逸路径。

沙箱限制的是文件，而非网络。 bubblewrap 的调用传入了 --unshare-pid，却没有传入 --unshare-net，因此网络命名空间仍与宿主共享。Seatbelt 配置为 (allow default)，在其上叠加 (deny file-write*)。于是环回地址从沙箱内部即可访问。该项目受影响版本的 CLI 参考文档也明确说明：在默认设置下，读取与网络访问并不受限。

本地 API 依据客户端提供的请求头判定信任。 一个名为 isTrustedApiRequest 的函数读取 Host 请求头，只要其值属于环回权威或出现在配置的 trustedHosts 列表中即放行。它从未将该值与连接实际的对端地址进行比对。针对它当初设想的威胁——DNS 重绑定，浏览器无法伪造 Host——这一检查是有效的；但面对不受浏览器规则约束的客户端则无效。该文件中的注释已说明这一点：按作者自己的措辞，这项检查 “is not an auth layer”（不是认证层）。

常规 shell 调用无需审批。 只有当命令请求超出会话既有权限的访问时，审批才会触发。这次逃逸并未请求任何权限，而是直接修改了会话设置。

智能体（沙箱内）
   │  bash 工具调用 —— 无需审批
   ▼
curl → http://127.0.0.1:<端口>/…   Host: <环回权威>
   │  isTrustedApiRequest() 读取请求头，而非对端地址
   ▼
会话模式 := danger-full-access，审批 := never
   │
   ▼
其后所有命令均在无限制、无提示的状态下执行

此外，该框架还会把这一接口的地址与当前会话标识直接交给智能体的 shell，因此连探测环节都可以省去。

OX 记录的会话日志中有两处细节值得留意。日志里没有出现任何 approval/request 事件。而这次策略变更被归属为 source: {kind: 'user'}——该框架无法区分自身智能体的 shell 与键盘前的真人。 OX 还做了配对对照实验：两个会话，采用相同的默认预设，执行同一条写入工作区之外路径的命令。事先发起过该调用的会话写入成功，另一个则被拦截。沙箱一直在正常工作，直到有人请它停下。

只要该端口可从外部访问——通过隧道、反向代理、SSH 转发或编辑器端口转发——就存在第二条路径。届时未经认证的远程调用方即可操控该智能体，并在没有 API 密钥、不触发模型调用的情况下下载全部已存储的会话记录。

为什么重要

本地逃逸唯一的前提，是智能体执行了一条由攻击者提供的文本所诱导的命令。而这恰恰是沙箱存在的意义所在——要遏制的正是这类输入。因此，这项控制措施被它本应防范的对象击穿。这是一次围堵失效，而非过滤失效；而围堵本是过滤失效之后的退守层。

编码智能体框架之所以值得攻击，是因为它握有一个 shell，并以启动它的开发者的环境权限运行：源码树、构建与测试命令，以及该工作站所能触及的 SSH 密钥、云凭据和内部系统。我们此前报道过相邻的形态：作为智能体攻击面的 localhost、针对本地 MCP 服务器的 DNS 重绑定、框架与模型之间的权限边界，以及让攻击者代码在沙箱之外运行的仓库配置。这一模式反复出现，是因为智能体与管辖它的组件位于同一主机。

处置过程中有两点值得指出。社区成员早在 2026 年 8 月 13 日与 14 日就在项目的公开讨论区描述了同一条逃逸路径，比厂商渠道的报告早十一天。此外，修复版本 0.1.2-alpha.1（8 月 27 日）从未发布到 npm，而项目自身的安装说明正是把用户引向 npm；npm 上第一个修复版本是 8 月 30 日的 0.1.2-alpha.2。补丁若未抵达安装路径，就还算不上补丁。

项目的 SAFETY.md 写明该软件未经安全审计，且沙箱与审批提示并不保证隔离。这一声明是坦诚的，应当被视为一份规格说明，而非例行免责套语。

防御

把智能体的控制平面置于其触及范围之外。 如果能够更改会话权限级别的 API 可从沙箱内部访问，那么沙箱就只是建议性的。请隔离网络命名空间（bubblewrap 使用 --unshare-net，Seatbelt 显式声明 deny network*），或将控制 API 绑定到沙箱配置所拒绝的套接字上。这是可以推广到其他产品的通用修复思路。

切勿从客户端可控的请求头推导信任。 Host、Origin 与 X-Forwarded-For 均由调用方提供。“仅限本地”意味着校验对端地址，或者更好的做法是要求凭据——这正是修复所采用的方案：启动时打印一次性令牌，由浏览器换取签名 Cookie，之后每次调用都必须携带。

要管控权限变更本身，而不仅仅是特权操作。 审批只在命令请求更多访问时触发、却在某次调用直接授予权限时保持沉默，等于让整条提权路径处于无人看管状态。应将沙箱模式、审批策略或允许列表的任何修改，都视为系统中审批等级最高的操作。

让审计记录能够区分行为主体。 明明源自智能体 shell 的策略变更却被记为来自”用户”，会同时破坏检测与取证。请为智能体发起的调用绑定独立的主体标识，并对携带该标识的任何权限变更发出告警。

审查你已经在运行的东西。 升级到修复版本之后的版本；核查任何第三方桌面封装所内置的框架版本，因为封装维护者各自固定自己的副本。移除会暴露智能体本地接口的隧道、代理与编辑器端口转发。在无法验证围堵有效性的场合，应假定被攻陷的会话拥有开发者的完整权限，并据此收缩凭据范围。

还需注意修复没有改变的部分：沙箱依然不限制读取与网络访问，智能体的 shell 依然会拿到该接口的地址。认证关上了那扇敞开的门，却没有把门移出房间。

状态

项目	详情
参考编号	CVE-2026-82533（VulnCheck 作为 CNA），CWE-807 —— 在安全决策中依赖不可信输入
严重性	CVSS 9.4
受影响版本	DeepSeek Harness（dsh）0.1.1-rc.2 及更早版本
社区报告	项目讨论区公开报告，2026 年 8 月 13 日与 14 日
披露	2026 年 8 月 24 日报告给 VulnCheck
修复	0.1.2-alpha.1，2026 年 8 月 27 日（仅 GitHub）；npm 上首个修复版本为 0.1.2-alpha.2，2026 年 8 月 30 日
验证	OX Research 于 2026 年 8 月 30 日复测并确认已修复
公开时间	CVE 记录与 OX 分析，2026 年 9 月 8 日
残留缺口	沙箱仍不限制读取与网络；智能体 shell 仍会获得控制接口地址