DeepSeek Harness 允许沙箱环境中的攻击者仅通过将 HTTP Host 请求头更改为 127.0.0.1 即可运行任意命令，其 CVSS 评分高达 9.4。该漏洞表明，一个错误的信任决策就能将保护边界变成一个敞开的后门。

漏洞是如何混入的

漏洞代码存在于一个单一函数中，该函数读取请求的 Host 请求头，如果其值等于回环地址，则将请求视为来自本地机器。

一个能够在沙箱内执行代码的攻击者不需要复杂的有效载荷。通过发送一个带有 Host: 127.0.0.1 的 HTTP 请求，后端会认为该调用源自主机本身，从而跳过所有安全提示、速率限制检查和命令验证步骤。结果是：无需进一步交互即可执行不受限制的命令。

为什么信任请求头是危险的

请求头是由调用方提供的纯文本字符串。无论字段名为 Host、X-Forwarded-For 还是任何自定义名称，客户端都可以将其设置为任何想要的值。关于连接真实来源的唯一可靠事实来源是传输层——即操作系统在 TCP 握手完成时记录的套接字（socket）源 IP 地址。

当应用程序决定信任一个请求头，而没有确认该请求头是由已知且配置正确的代理注入时，它实际上是将通往核心的钥匙交给了攻击者。DeepSeek Harness 漏洞就是这一失误的教科书级案例。

现实世界的影响：shell.online 案例

开源项目 shell.online 提供基于 Web 的终端，最近也记录了同样的陷阱。它使用了一个名为 TRUST_PROXY 的配置标志：

  • TRUST_PROXY = 0 – 应用忽略 X-Forwarded-For 请求头，并依赖套接字的远程地址。这可以防止客户端伪造 IP 地址以规避速率限制或冒充受信任用户。
  • TRUST_PROXY = 1 – 应用将 X-Forwarded-For 请求头视为客户端身份。如果服务背后没有实际的代理来清洗该请求头，攻击者可以在每个请求中提供一个新的 IP 地址，从而有效地重置任何基于 IP 的限流。

DeepSeek 漏洞反映了这种情况：代码像对待代理设置的请求头一样信任了 Host，但该服务实际上是可以被直接访问的。

开发人员现在需要做什么

  1. 审计所有读取客户端提供请求头的地方。 识别哪些请求头被视为权威来源（例如 Host、X-Forwarded-For、X-Real-IP），并验证在到达您的应用程序之前，已确保受信任的代理对其进行了重写。
  2. 尽可能将安全决策与套接字地址绑定。 使用操作系统提供的源 IP 进行身份验证、速率限制和访问控制检查。
  3. 仅在服务前方部署了配置正确的反向代理时，才启用代理信任标志。 如果您直接运行应用，请保持这些标志处于禁用状态。
  4. 在项目的 README 或部署指南中记录所需的部署拓扑，以便进行自托管的用户了解代理信任的要求。
  5. 运行静态分析或代码审查工具，以标记那些在没有配套代理验证逻辑的情况下，直接使用请求头进行安全决策的行为。

下一步值得关注什么

在此事件发生后，提供自托管 Web 服务的社区很可能会重新检查其自身的代理信任设置。

核心教训是深刻的：永远不要让互联网上任何人都可以编写的一段文本来决定系统的安全态势。要信任网络层，而不是请求层。