The State of DeepSeek Harness Security, Two Weeks In
纯防御视角的 DeepSeek Harness 安全现状综述：官方已修复什么、社区报告了哪些未验证问题，以及你现在能做的具体防护措施。
DeepSeek Harness（dsh）上线两周后，目前有一个官方已确认修复的漏洞（Bubblewrap 沙箱绕过，已在 0.1.1-rc.1 修复），以及一份更长的社区报告的信任模型问题清单——截至本文撰写时仍未官方确认，也未经我们独立验证。这篇文章是防御视角的现状综述，不是"怎么利用"的教程：它告诉你什么已经修好、什么是报告了但未确认的，以及你今天就能采取的具体防护措施。
官方已修复的问题
目前唯一有明确官方修复记录的漏洞，是 通过 /proc/<pid>/root 绕过 Bubblewrap 沙箱限制的问题，已在 v0.1.1-rc.1 发布（2026-08-21）中修复。release notes 把它列在"修复"条目下，与一个表格布局修复、缓存命中率显示精度优化并列——dsh 并没有专门的安全公告格式，所以常规 release notes 里的这一行，就是目前最接近"正式安全披露"的东西了。我们不在这里复述具体的绕过手法；如果你想了解机制，release notes 原文那句"受限进程可经 /proc/<pid>/root 绕过限制"已经说明了问题所在。
第二个已确认的修复更偏流程而非代码层面：dsh 的文档站此前是"每次 push 到 master 分支即部署"，意味着未发布的内容可能在正式打标签发布之前，就先泄露到无鉴权的公开 Pages 站点上。这个流程被改为按 release tag 门禁部署——文档站现在只在 workflow_dispatch 触发时重建，并复用与 npm 发布相同的 ref 校验门禁。与其说是运行时安全修复，不如说是供应链卫生修复，但它确实堵上了"提前偷看未发布路线图"这个真实的泄露口子。
这两个修复来自同一个发布周期，这也符合 dsh 目前的定位：它仍处于开发者预览阶段，没有 SemVer 承诺，发布节奏很快（截至 2026-08-21，5 天内发了 3 个 npm 版本——具体每版改了什么见 DeepSeek Harness 升级指南）。如果你想了解这两个修复所依托的整体权限模型，可以从 DeepSeek Harness 权限与沙箱详解 看起。
社区报告的信任模型问题
2026-08-18，一份相对系统的第三方问题汇总在 X 上流传（来源，社区报告，未经我们独立验证）。下面我们用防御性、不含利用步骤的方式列出这些问题——只说风险是什么、怎么降低风险，不说怎么触发。
| 社区报告的问题 | 为什么重要 | 来源 |
|---|---|---|
| Web UI 没有认证层（无 token、cookie、TLS） | 任何能访问该端口的本地进程都可能代表你执行操作 | 社区报告 |
绑定 0.0.0.0 会自动把局域网 IP 加入信任主机列表 | 同网段任意主机可能获得同等的未鉴权控制权 | 社区报告 |
| 未鉴权的 loopback RPC 可读取完整会话内容 | 一个没有 dsh 自身界面的本地进程仍可能看到你做过什么 | 社区报告 |
插件安装即在宿主进程立即执行 JS，dsh plugin remove 后可能残留 | "安装"一个插件并非沙箱化预览，而是立刻在你的机器上执行 | 社区报告 |
AGENTS.md/CLAUDE.md 指令注入无需安装、无需批准即可触发 | 不受信任的仓库内容可能在你有意识授权之前就左右 agent 行为 | 社区报告 |
| workflow 工具的 VM 沙箱隔离据称可被绕过 | "无文件系统/网络/定时器访问"这一声明的隔离范围存在争议 | 社区报告 |
在 workspace-write 下，模型据称可经由 Web 批准回环通道自我批准，提权到 danger-full-access | 原本要求人工点击的那道防线据称可被绕过 | 社区报告 |
这条推文把上述内容归结为一个核心矛盾：dsh 把模型行为当作生产级可靠对待，但插件代码执行几乎没有对应的安全设计。这个概括是公允的——这些问题大多不是什么奇技淫巧的零日漏洞,而是"你以为存在的信任边界，其实还没建立"。同一条推文也提到社区已经在针对这些问题构建防御工具——见下文"用户防护清单"一节。
我们没有独立复现环境去验证这份清单里的任何一条，所以请把这张表当作"需要保持警惕、等待官方确认"的问题清单,而不是已确认的 CVE。
独立评测视角
另外两个更审慎、可追溯来源的观点值得完整阅读：
- magnus919.com 指出，dsh 的本地沙箱限制的是写入位置，但不限制进程可见性和网络出口——如果你带着基于容器的"沙箱化"心智模型来理解，它的保护范围其实比想象中窄。
- Wavect 认为 dsh 目前适合小范围试点，考虑到开发者预览阶段的状态和上面提到的信任模型缺口，还不是一个可以在没有额外防护的情况下直接托付生产工作负载的控制面。
这两个来源都不是正式的安全审计报告，我们将其作为有见地的技术评论引用。
用户防护清单
这是本文最具操作性的部分。以下建议都不需要深厚的安全专业知识——它们只是配置选择和使用习惯。
- 绝不绑定
0.0.0.0。 Web UI 只绑127.0.0.1。如果需要远程访问，用你自己受信任的隧道（SSH 端口转发、Tailscale 等），而不是直接暴露端口——dsh 官方自己也把0.0.0.0支持称为"出于安全考虑暂不支持"。 - 默认使用
workspace-write+ 谨慎审批，而非danger-full-access。 在放宽权限之前先搞清楚每个权限预设实际限制了什么——完整的沙箱模式与审批策略拆解见 DeepSeek Harness 权限与沙箱详解。 - 装插件前先审查，而不是装完再说。 由于安装会立即在你的宿主进程中执行代码，对待
dsh plugin add应该像对待从不熟悉的 registry 安装npm install一样谨慎。装任何没验证过的插件之前，先过一遍 DeepSeek Harness 插件安全检查清单。 - 用隔离的 profile 试用陌生插件，不要直接装进日常用的 profile——
dsh plugin --profile <name> add ...按 profile 隔离安装，这样一个有问题的插件装在临时 profile 里就不会碰到你的主工作区。 - 锁定某个 commit 或版本，而不是始终跟随
latest，尤其是在 CI 或自动化脚本里。这也能避免你在回归 bug 刚发布的当天就中招。 - 及时升级到 0.1.1-rc.1，拿到上文提到的沙箱修复——升级过程中还改了什么、rc.6→rc.8 这轮有哪些 breaking change，见 DeepSeek Harness 升级指南。
- 敏感仓库不要放进 dsh 指向的工作区，尤其是在上述信任边界问题还悬而未决的阶段。把工作区根目录当作半信任环境，而不是私有空间。
- 考虑使用社区扫描工具——有几个插件专门为 dsh 原生不具备的这层防御而生：dsh-poison-guard（插件投毒扫描器）、dsh-skill-security-guard（信任一个 Skill 之前先扫描）、以及 dsh-guardian（危险命令的运行时防护）。这些都是社区项目，不代表官方背书——安装前请用第 3 条同样的检查清单去审查它们。
提示注入：所有 agent harness 的共性风险，不是 dsh 独有
AGENTS.md/CLAUDE.md 以及仓库内其他文件内容成为指令注入的载体，并不是 dsh 独有的问题——这是所有会自动把工作区文件折叠进上下文的 agent harness 都存在的结构性风险（dsh 默认会把每个新 session 里最多 65,536 字节的 AGENTS.md/CLAUDE.md 渲染进上下文）。有一篇 arXiv 论文评测过针对 agent harness 的间接提示注入成功率，但我们没有独立核实其方法论和具体数字，所以这里不引用具体数据——只想说明这类风险确实存在，且正在被持续研究。实际的缓解方式和对待任何不受信任输入一样：在把 agent 指向某个仓库之前先看一眼它的 AGENTS.md，不要对自己没有创建的工作区授予 danger-full-access。
展望
dsh 仍处于开发者预览阶段，没有 SemVer 承诺，大约每隔几天就发一版——按照官方 README 自己的说法，会有破坏性变更是明确写在台面上的。这个阶段的安全边界是一个移动靶：今天社区报告的缺口，可能下周就被修复了，也可能因为没有正式的 CVE 流程、反馈全靠 GitHub Discussions 而不是安全邮件列表,而在相当一段时间内保持开放。现阶段最有用的习惯就是保持关注——盯着 Discussions 和 release notes，而不要假设今天的威胁模型下个月依然成立。
FAQ
DeepSeek Harness 安全吗？
如果你遵循上面的防护清单——只绑 127.0.0.1、用带审批的 workspace-write、装插件前先审查——它对于范围可控、不涉敏感数据的本地工作流来说是够用的。但考虑到它还处于开发者预览阶段，且存在若干未解决的、社区报告的信任模型缺口，我们暂不建议在没有额外防护的情况下，把生产凭据或敏感仓库直接托付给它。
目前唯一确认的 dsh 漏洞是什么？
通过 /proc/<pid>/root 绕过 Bubblewrap 沙箱，已在 v0.1.1-rc.1 修复。这是唯一有官方补丁和公开 release notes 记录的问题；本文提到的其他内容要么是社区报告且未经验证，要么是独立第三方评论。
为什么不能把 Web UI 绑定到 0.0.0.0？
因为 Web UI 没有认证层——没有 token、cookie 或 TLS——绑定到所有网卡意味着同网段的任何人都能获得等同于本地远程代码执行的控制权。dsh 官方文档自己也把 0.0.0.0 支持描述为"出于安全考虑暂不支持"。
dsh-poison-guard、dsh-skill-security-guard、dsh-guardian 是官方安全工具吗？
不是——它们是社区开发的插件，不是 dsh 官方安全产品。可以把它们当作额外的一层防护，但安装前要用对待任何其他插件一样的审查清单去评估它们，再考虑装进受信任的 profile。
沙箱能完全隔离 agent 的行为吗？
按独立评测的说法，不能完全隔离：本地沙箱限制的是写入位置，但据称不限制进程可见性和网络出口。应该把沙箱化和上面提到的审批策略、工作区范围控制结合起来使用，而不是把"沙箱化"等同于"完全隔离"。
Next steps
想了解这些修复和报告所依托的完整权限模型，可以阅读 DeepSeek Harness 权限与沙箱详解，再装任何新插件之前过一遍 DeepSeek Harness 插件安全检查清单。如果你还在用旧版本，DeepSeek Harness 升级指南 讲清了升级到 0.1.1-rc.1 的路径以及升级过程中会踩到哪些坑。也可以在 FindHarness 的 Security & Permissions 分类下浏览经过筛选的安全类插件（含上文提到的几款）。