9 月 8 日公开的 CVE-2026-82533 描述了一条反常识的权限升级路径：DeepSeek Harness 中仍受文件沙箱约束的 Agent，只需让普通 shell 向同一台机器上的控制 API 发出一次请求，就能把当前会话切换为 danger-full-access，同时把审批策略改成 never。下一条命令便不再经过沙箱，也不会弹出人工确认。
这不是模型自主发现并攻破了操作系统隔离。攻击需要 Agent 先读到攻击者控制的内容，再受其诱导执行命令。真正失守的是运行框架内部的身份边界：Host 头原本只用于判断请求是否发往受信地址，却被无认证控制面当成了调用者可信的依据；文件沙箱又允许访问环回网络，于是“能连接本地服务”被误当成了“有权代表用户修改安全策略”。
三个单独合理的设计，拼成了完整逃逸链
DeepSeek Harness 的默认 workspace-write 模式主要限制文件写入范围。OX Security 核对 Linux 的 bubblewrap、Landlock 与 macOS 的 Seatbelt 配置后发现，受限进程仍可使用网络；普通 shell 调用本身也不需要审批。Harness 还会把 Web 地址和当前会话标识放进 shell 环境，Agent 无需扫描端口或猜测会话。
第二环是本地 Web 控制面。受影响版本的 isTrustedApiRequest 会读取客户端提交的 Host，只要它是环回地址或命中 trustedHosts 就放行；代码注释已经明确，这道检查负责抵御 DNS rebinding 和跨站请求，“不是认证层”。浏览器通常不能伪造 Host，普通命令行客户端却可以自行填写。更关键的是，默认本地场景根本不需要伪造网络来源：沙箱内进程与 Host 共用网络，天然能访问 127.0.0.1。
第三环是控制面的权限。它不仅展示界面，还能执行斜杠命令、修改会话权限、回答审批请求、创建会话和导出记录。公开复现的最短路径通过控制 API 执行 /permission danger-full-access；服务端按正常产品逻辑把会话改成无沙箱、无审批模式。原本只允许在工作区写文件的 shell，因此获得了启动 Harness 的操作系统用户所拥有的文件权限。
这条链条可以压缩为：恶意内容诱导 Agent 执行 shell → 受限进程访问环回控制面 → 控制面接受没有身份凭据的请求 → 会话策略被改写 → 后续命令脱离沙箱。每一步单看都服务于本地开发体验，组合后却让被约束的一方拿到了改写约束的接口。
默认本地安装可被提示注入利用，远程攻击还需要端口可达
漏洞在默认环回配置下成立，因为攻击者借的是 Agent 已经拥有的 shell 和环回网络，而不是从互联网直接连接用户电脑。必要前提是用户让 Agent 处理了攻击者可控的仓库、文档或网页内容，且 Agent 随后执行了其中诱导的命令；公开材料没有证明模型会在没有这类输入的情况下自行寻找这条路径。
远程威胁的门槛不同。DeepSeek Harness 随附的 CLI 拒绝监听 0.0.0.0，所以默认服务不会直接暴露在局域网或公网。只有用户或第三方封装通过反向代理、SSH 转发、编辑器端口转发或隧道让端口可达时，外部调用者才可能利用同一个缺口。VulnCheck 记录的后果包括创建会话、执行命令和导出保存的对话。
因此，9.4 的 CVSS 分数描述的是一组技术上可达到的严重后果，不等于每个本地用户都面临同样的远程暴露。对默认安装，最现实的风险路径是“提示注入借 Agent 现有权限进入本地控制面”；对已转发端口的部署，风险才扩展为无需凭据的远程控制。
修复没有改沙箱，而是给整个控制面加上身份
OX 的时间线显示，研究人员 8 月 24 日确认漏洞并向 VulnCheck 披露，DeepSeek 于 8 月 27 日在 0.1.2-alpha.1 中发布修复，8 月 30 日复测通过，CVE 于 9 月 8 日公开。对应提交没有试图靠继续收紧 Host 规则解决问题，而是在所有 Host API 调度之前加入浏览器会话认证。
新流程在每次进程启动时生成随机令牌，只允许启动链接用它换取签名 Cookie；API 路径不直接接受该令牌。Cookie 与具体主机名、端口绑定，并使用 HttpOnly 和 SameSite=Strict。普通 API、Remote 调用、WebSocket 流都要求同一个已认证会话。Host 与 Origin 检查继续承担路由和浏览器跨站防护，但不再负责证明调用者是谁。
这项修复没有取消 Agent 的网络访问，也没有把普通 shell 改成每次都需批准。它切断的是“受限进程能到达控制面，所以可以冒充浏览器用户”的等号。除非 Agent 还能取得有效启动令牌或 Cookie，仅知道环回地址和会话 ID 已不足以修改策略。
分发时间线也决定了用户该检查什么。GitHub 在 8 月 27 日已有 0.1.2-alpha.1 标签，但 The Hacker News 复核 npm 后发现，该版本没有发布为可安装包；8 月 30 日的 0.1.2-alpha.2 才是 npm 上首个带修复的版本，9 月 3 日的 0.1.2-rc.1 继续包含修复。直接使用 npm 的用户应至少升级到 0.1.2-alpha.2，通过桌面封装或其他集成安装的用户则要核对封装实际携带的 Harness 版本，而不是只看外层应用版本。
本地控制面必须把“可达”与“有权”分开
这次漏洞给其他 coding-agent harness 的启示，不是简单关闭环回网络。Agent 合法工作往往需要下载依赖、调用 API 和访问本地开发服务；把网络全部切断会直接破坏工具价值。更稳固的边界是把控制面视为持有 shell 权限的特权服务：所有能创建会话、执行命令、修改策略、读取凭据或回答审批的入口统一认证，服务器端验证授权，不能只依靠前端弹窗、来源地址或可由客户端填写的请求头。
版本管理同样属于这条安全边界。源码标签出现并不表示用户通过包管理器已经能拿到修复，第三方封装还可能长期固定旧依赖。维护者需要同时发布安全说明、可安装构件和清晰的最低安全版本；使用者则应核对实际运行包，而不是依据 GitHub 页面判断升级完成。
DeepSeek Harness 的安全说明现已明确：项目仍是未经安全审计的开发者预览软件，沙箱和审批只能降低风险，不能作为处理不可信工作负载的唯一防线。CVE-2026-82533 把这条抽象警告具体化了——当 Agent、浏览器和控制 API 共享一台机器时，本地地址只说明请求从哪里能到达，不能说明谁有权替用户关掉护栏。
