DeepSeek Harness被认为是今年最受关注的开源项目之一。它在8月13日正式开源，使用MIT协议，仅在三天内，GitHub上的星标数量便从4.5万跃升至14万。可是，8月24日，奇安信威胁情报中心发布了警告，指出其存在一个严重的未授权远程代码执行漏洞，编号为QVD-2026-57410，风险等级极高，CVSS评分达到9.8，并且相关的POC和技术细节已被公之于众，奇安信CERT已经验证其可行性。目前尚未分配CVE编号，且未观察到该漏洞的实际利用情况。从开源到被提出严重漏洞，仅相隔11天。

首先要了解的是DeepSeek Harness的性质。它被命名为dsh，是DeepSeek推出的Agent运行框架，官方标识非常简洁：AGENT = MODEL + HARNESS。它的功能是将模型的思考与执行结合起来，负责工具调度、Bash执行、文件操作、会话管理和子Agent的派遣，所有功能通过插件进行组合，而底层则是使用Cordis插件的元框架。值得注意的是，它并不是强制绑定特定模型，其官方文档中涵盖了Anthropic、OpenAI、Google、Azure等多个提供商，目标明确是与Claude Code和Codex竞争。此外，官方已经声明，项目仍在开发者预览阶段，未来可能会出现重大的变更。

DeepSeek的战略意图也十分明确。在8月13日的发布会上，DeepSeek同时推出了V4 Pro的正式版本以及API涨价的预告，这表明该公司希望在不断激烈的模型竞争中，保持对开发者的控制权。因为过去两年间，很多开发者日常使用的IDE和Agent工具基本被Claude Code和Cursor所占据，而Harness就是DeepSeek将自己的模型链接到其定义的执行层的关键步骤。该框架掌握了高权限的工具，可直接执行Bash、读写文件系统和执行代码，因此安全性显得尤为重要。漏洞的曝光正是与这种高权限特性密切相关。

该漏洞的攻击路径相对简单：攻击者只需伪造Host请求头，便可获取服务器权限。漏洞的核心在于dsh的Web服务依赖HTTP Host请求头来判断请求是否来自本机回环地址，从而保护/api后面的高权限RPC接口。然而，Host头是客户端可以随意设置的字段，因此使得这个信任机制异常脆弱。攻击的完整步骤是不需有效的API Key或真实的模型，攻击者只需注册一个伪造的大模型提供者，利用该虚假提供者促使dsh执行系统命令，最终通过dsh服务进程的权限完全掌控主机。这一过程说明，在Agent框架中，攻击者不需要找到特权提升的路径，因为bash工具本身就是框架的基本功能。

此外，攻击链中隐藏着更深的风险。注册虚假的LLM提供者依赖llm.discoverModels接口去访问攻击者指定的地址，如果这一路径的目标地址范围不受约束，同样的手段有可能被用于探测内网或获取云元数据凭据，构成典型的SSRF攻击。因此，奇安信在修复建议中特意提到需限制访问范围。

虽然漏洞的风险不容小觑，但我们也要看2023年内的默认安装是相对安全的。dsh的Web UI默认绑定在127.0.0.1:3080，只监听本地回环，外部无法直接访问。然而，高危的情况出现在以下三种部署方式中：将管理API暴露到公网；通过Docker的端口映射将服务移至非回环网络；以及对外提供访问的反向代理未在代理层进行严格的Host头校验。攻击者利用这一漏洞，还需有目标实例能够访问的服务器，因此这些条件并不容易齐全。经确认，受影响的版本为0.1.1-rc.2。考虑到Harness正处于预览阶段，而很多团队近期正开始搭建评估环境，现在正是自查的最佳时机。

自查可以聚焦于三项具体操作：检查dsh进程是否仅绑定在127.0.0.1；查看Docker容器的端口映射是否将类似于3080的管理端口泄露；如果使用了Nginx等反向代理，务必确保代理层对Host头进行了白名单校验。每一项检查都建议务必采取相应措施处理。

奇安信的修复建议如下：首先，实施网络隔离是最有效的措施，立即将dsh管理API端口从公网隔离，只允许可信的内网IP访问；若有远程访问的需求，则需在反向代理层增加真实身份的认证（如mTLS、SSO及IP白名单）。其次，应在Nginx等前端代理中配置严格的Host头校验规则，只放行合法的域名或IP。最后，从架构上修复，/api信任的围栏需要引入独立于Host头的认证体系，特权RPC的保护不能仅依靠回环地址的检测；llm.discoverModels接口也要限制目标地址范围，以防止SSRF带来的数据泄漏风险。同时，用户应定期关注DeepSeek官方的安全通知，及时升级到修复版本。

尽管就技术层面而言，Host头伪造属于Web安全基础知识中的常见错误，但其产生的漏洞背后则反映出安全设计上的深刻教训。