[Security]SSRF protection bypass via HTTP proxy routing in DeepSeek Harness web_fetch (dsh v0.2.1-alpha.1)

[rockmelodies]

1. Product Introduction

DeepSeek Harness (dsh) is an open-source AI-agent harness developed by DeepSeek AI. Built on an "everything-is-a-plugin" Cordis architecture, it executes model-generated code and commands, loads third-party plugins, and accesses the network, processes, credentials, and files. It launches through named profiles (web, headless, sdk, acp); the web profile enables the model-facing web_search and web_fetch tools by default. This vulnerability resides in the web_fetch HTTP provider (@deepseek-ai/dsh-web-fetch-http) and the outbound proxy routing library (@deepseek-ai/dsh-http-proxy).

2. Vulnerability Title

SSRF protection bypass via HTTP proxy routing in DeepSeek Harness web_fetch (dsh v0.2.1-alpha.1)

3. Summary / Description

DeepSeek Harness v0.2.1-alpha.1 is affected by a Server-Side Request Forgery (SSRF) protection bypass in the web_fetch tool. When the deployment has an HTTP(S) proxy configured (HTTP_PROXY / HTTPS_PROXY / ALL_PROXY), outbound requests take a proxied branch that skips the destination-IP validation (resolvePublicAddresses) entirely. An attacker who controls content the agent reads (indirect prompt injection) can therefore make the agent fetch a hostname that resolves to a private/loopback/link-local/cloud-metadata address — e.g. http://169.254.169.254.nip.io/ or http://metadata.internal/ — and the proxy will resolve and connect to that internal target, leaking cloud-metadata credentials or probing internal services. No authentication is required; the impact is on confidentiality.

4. Technical Analysis / Root Cause

Weakness: CWE-918 — Server-Side Request Forgery (SSRF)

Source-to-sink chain:

model-controlled url arg (packages/web/tool-web/src/fetch.ts:460, 499-504)
  → ctx.web.fetch (packages/web/web/src/index.ts:157-163)
  → HttpFetchProvider.followAndRead → validateFetchUrl (http/https + no creds + length only)
  → requestOnce proxied branch (packages/web/web-fetch-http/src/provider.ts:134-137)
       if route.proxied && !isNonPublicIpLiteral(hostname) → requestVia()  // no IP validation
  → fetch(url, { dispatcher }) — the proxy resolves and connects (network.ts:229-239)

Code location:

File: packages/web/web-fetch-http/src/provider.ts
Line: 134-139
Relevant code:
  const route = proxyRouteFor(url)
  if (route.proxied && !isNonPublicIpLiteral(url.hostname)) {
    return await publicHttpNetwork.requestVia(route.dispatcher, url, headers, signal)  // no IP check
  }
  const addresses = await this.resolveAddresses(url.hostname, signal)                  // SSRF guard
  return await publicHttpNetwork.request(url, addresses, headers, signal)

File: packages/web/web-fetch-http/src/network.ts
Line: 171-174
Relevant code (the only guard on the proxied branch; literal IPs only):
  export function isNonPublicIpLiteral(hostname: string): boolean {
    const unbracketed = stripIpv6Brackets(hostname)
    return isIP(unbracketed) !== 0 && !isPublicIpAddress(unbracketed)
  }

File: packages/util/http-proxy/src/policy.ts
Line: 338-343
Relevant code (routing decision compares the hostname STRING, never resolves it):
  export function proxyForUrl(policy, url) {
    const proxy = url.protocol === 'https:' ? policy.httpsProxy : ... policy.httpProxy : undefined
    if (proxy === undefined) return undefined
    if (isLoopbackHost(url.hostname)) return undefined
    return bypassesProxy(policy.noProxy, url) ? undefined : proxy
  }

Validity check:

• Reachable: ✅ web_fetch is enabled by default (packages/bundle/base/cordis.patch.yml:476,489).
• Controllable: ✅ the url is a model tool argument, driven by indirect prompt injection.
• Propagable: ✅ no IP validation / allow-list sits between source and sink on the proxied branch.
• Exploitable: ✅ the proxy resolves and connects to internal/metadata targets; the response flows back into model context.
• Bypassable: ✅ isNonPublicIpLiteral only rejects IP literals; hostnames (*.nip.io, internal DNS names, DNS-rebinding domains) bypass it.
• Reproducible: ✅ the bundled POC reproduces stably (Section A decision table + Section B end-to-end).
• Impact established: ✅ reads AccessKeyId/SecretAccessKey/Token from a fake metadata service.
• Impact scope: ✅ chains with indirect prompt injection into credential theft and internal-network reconnaissance.

Root cause: requestOnce() conflates "is this request proxied" with "can we skip destination validation". The proxy branch skips resolveAddresses on the assumption that there is no locally-resolvable address (DNS happens proxy-side) — but failing to validate is exactly what lets an attacker hand over a hostname that resolves to an internal address. The only guard on that branch, isNonPublicIpLiteral(), uses net.isIP() and therefore can never classify a hostname.

5. Affected Versions

• Affected: dsh v0.2.1-alpha.1 (current tag) and earlier versions that ship the proxied web_fetch path.
• Tested version (the version this research targeted and reproduced on): dsh v0.2.1-alpha.1. Verified from two sources:
  1. Source checkout: git describe --tags = dsh-v0.2.1-alpha.1 (the @deepseek-ai/dsh-web-fetch-http package package.json version = 0.2.1-alpha.1);
  2. Official npm package: @deepseek-ai/dsh@0.2.1-alpha.1 (with @deepseek-ai/dsh-web-fetch-http@0.2.1-alpha.1), booted as a live Web target at http://127.0.0.1:3080 and confirmed reachable.
• Not affected: none confirmed. (With no proxy configured, the direct path's SSRF guard works; this flaw manifests only when a proxy is configured.)
• Fixed version: no fix available as of the report date.
• Tested environment: Node.js v22.22 (repo engines requires ^22.19 || >=24), Windows 11; the server-side reproduction uses only built-in node:http/node:net (the POC has no third-party dependencies).

6. Severity

Item	Value
CVSS v3.1 score	8.6
CVSS v3.1 vector	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N
CVSS v4.0 vector (supplementary)	CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N
Rating	High

Scoring rationale: no account needed (attacker only controls content the agent reads → PR:N), network-reachable (AV:N), no user interaction (UI:N), scope changed — internal/metadata services in a different trust zone (S:C), high confidentiality impact (C:H); the request is GET-only so I:N/A:N. The precondition "a proxy is configured" is stated explicitly in §3/§5 (folded into AT:P in the v4.0 vector).

7. CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N = 8.6 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N (High; AT:P reflects the proxy precondition)

8. Reproduction Steps

8.1 Environment

• Product/version: DeepSeek Harness dsh v0.2.1-alpha.1 (tested version)
  • Source checkout: git describe --tags = dsh-v0.2.1-alpha.1
  • Official npm package: @deepseek-ai/dsh@0.2.1-alpha.1 (live Web target at http://127.0.0.1:3080)
• OS/runtime: Windows 11 / Node.js v22.22 (the POC uses only built-in node:http/node:net)
• Network position: local (POC self-hosts a fake metadata service and a forward proxy on 127.0.0.1; Burp proxy at 127.0.0.1:8080)
• Test account: none

8.2 Steps

Step 1 — Set up the environment
Run the bundled POC. It starts a fake "instance metadata" HTTP service on 127.0.0.1:18080 returning example AccessKeyId/SecretAccessKey/Token, then a minimal forward proxy on 127.0.0.1:18081 whose resolver maps *.internal hostnames to 127.0.0.1 (mimicking a real proxy's resolver).

Step 2 — Show the routing decision
POC Section A prints each URL's decision under an active proxy:

127.0.0.1               isNonPublicIpLiteral=true  -> DIRECT (resolveAddresses rejects)
169.254.169.254         isNonPublicIpLiteral=true  -> DIRECT (resolveAddresses rejects)
169.254.169.254.nip.io  isNonPublicIpLiteral=false -> PROXIED (resolveAddresses skipped)
metadata.internal       isNonPublicIpLiteral=false -> PROXIED (resolveAddresses skipped)

Step 3 — Trigger and observe (end-to-end)
POC Section B requests http://metadata.internal:18080/latest/meta-data/... through the proxy; the proxy resolves it to 127.0.0.1 and hits the metadata service:

proxy response (HTTP 200):
{"Code":"Success","AccessKeyId":"ASIA-EXAMPLE-METADATA-KEY","SecretAccessKey":"wJalrXUtnFEMI/EXAMPLE-METADATA-SECRET","Token":"IQoJb3JpZ2luEXAMPLE-TOKEN"}

Step 4 — Verify impact
In a real deployment, replace the hostname with http://169.254.169.254.nip.io/latest/meta-data/iam/security-credentials/ (AWS), http://metadata.google.internal/... (GCP), or an internal hostname to read cloud-metadata credentials or probe internal services; the response is returned into the agent context via web_fetch, ready for the attacker to induce exfiltration.

9. Proof of Concept

9.1 Format selection

• Chosen format: custom self-contained Node.js script (no third-party dependencies).
• Rationale: the bypass is a two-step "routing decision + proxy-side resolution" and is clearest as a runnable script that mirrors the source line-by-line.

9.2 Usage

• Runtime: Node.js ≥ 18
• Dependencies: none
• Run: node poc/poc-ssrf-proxy.js
• Disclaimer: for authorized testing and vulnerability verification only.

9.3 POC Code

See poc/poc-ssrf-proxy.js in this directory (Section A decision table + Section B end-to-end demo; self-hosted on 127.0.0.1, read-only, non-weaponized).

9.4 Expected output / success criteria

Section A shows hostnames mapped to PROXIED (resolveAddresses skipped); Section B shows the proxy returning AccessKeyId/SecretAccessKey/Token from the fake metadata service.

10. Mitigation / Fix Recommendations

10.1 Temporary mitigations

• Disable web_fetch (tool-web.fetch: false) in environments that process untrusted content, or remove/tighten the outbound proxy.
• Explicitly list internal/metadata domains in NO_PROXY (including *.nip.io, metadata.*) so they take the direct path and are caught by the SSRF guard. Note: list-based filtering is leaky and is only a stopgap.

10.2 Root-cause fixes

• On the proxied branch, resolve and validate the destination BEFORE proxying: run resolvePublicAddresses and reject private/loopback/link-local/metadata addresses, or at minimum block 169.254.169.254, private-range hostnames, and *.nip.io/DNS-rebinding domains before routing to the proxy.
• Move public-only destination enforcement into the shared outbound policy layer so the direct and proxied paths use one set of deny/allow rules instead of diverging.
• Re-validate every redirect hop on the proxied path (already done on the direct path).

10.3 Verification

Re-run the POC: with a proxy configured, web_fetch against metadata.internal / 169.254.169.254.nip.io should return WEB_BLOCKED_URL (or equivalent), and the proxy should receive no corresponding outbound connection.

11. False-Positive Elimination / Impact Justification

False-positive verification:
- Existence: ✅ reproduced stably with the bundled POC (web_fetch enabled by default + proxy configured)
- Characterization: ✅ a real SSRF (CWE-918) with a confidentiality impact
- Exploitability: ✅ no auth (PR:N), network-reachable (AV:N), triggered via indirect prompt injection
- Novelty: ✅ distinct from the earlier direct-path SSRF report (now fixed); same component, new proxy-path bypass; no public ID/detail
- Evidence: ✅ source-to-sink code location + runnable POC + decision-table / end-to-end output
- Code-audit validity: ✅ reachable/controllable/propagable/exploitable/bypassable/reproducible/impact established/impact scope
Conclusion: confirmed real, exploitable, and previously undisclosed — ready for submission.

Appendix A: Timeline / References

Date	Event
2026-10-09	Discovered and verified

• Project: https://github.com/deepseek-ai/deepseek-harness
• Related CVE/CNVD/CNNVD: none

Appendix B: Evidence Checklist

• Source-level root-cause evidence (audit-findings.md, with file:line and key code)
• Runnable POC (poc/poc-ssrf-proxy.js, decision table + end-to-end output)
• Reproduction screenshots (can be added later under evidence/ per §8)
• HTTP request/response capture (the POC already prints the proxy response)

[rockmelodies]

poc-ssrf-proxy.js

[PerryLink]

你的代码引用逐字准确，这一点我核过了。但定性不成立：这是有文档的有意设计，而且设计笔记自己就写明"代理被信任做目标选择"。建议把诉求从"绕过漏洞"改成"请复核这条边界是否仍然要维持"。

1. ✅ 你引的代码我都核了（origin/master = 571902028a，2026-10-14）

packages/web/web-fetch-http/src/provider.ts：

• :134 → const route = proxyRouteFor(url)
• :135 → if (route.proxied && !isNonPublicIpLiteral(url.hostname)) {
• :136 → return await publicHttpNetwork.requestVia(route.dispatcher, url, headers, signal)
• :138 → const addresses = await this.resolveAddresses(url.hostname, signal) ← 确实不在 :136 那条分支上
• :171-174 → isNonPublicIpLiteral(...) 用 isIP()，只认字面量（无法分类主机名）

packages/util/http-proxy/src/policy.ts:338-343 的 proxyForUrl 也逐字一致。

⇒ "代理分支不做本地解析与钉死"是事实。

2. ⚠️ 但这是记录在案的有意取舍，不是疏漏

.agents/notes/implemented/architecture/2026-08-27-outbound-proxy-policy.md:39：

Through a proxy, web_fetch stops resolving and pinning. … configuring a proxy is a statement that the proxy is trusted with destination selection.

同一笔记 :81 还自认这是对外安全承诺的一次变更：

This is the one outward-facing security promise the change alters.

⇒ 把这条叙述成"实现缺陷"，维护者的第一反应会是"这是我们写下来的设计"。这一句必须自己先说出来，否则整条报告会被定性为误读。

3. 被挡住的字面量（面已经收窄到这一档）

• docs/user/guide/network-proxy.md:71 → 「web_fetch to a literal private address. A URL naming an address like http://10.0.0.5/ is refused rather than handed to the proxy」
• 测试 packages/web/web-fetch-http/tests/proxy.spec.ts:112-127 用 10.0.0.5 / 169.254.169.254 / 127.0.0.2 断言 WEB_BLOCKED_URL 且 proxied == []；:136 断言 isNonPublicIpLiteral('example.com') === false

⇒ 字面量私网/元数据地址是被拒的。未覆盖的只有主机名这一档。

4. 另外两条边界（建议一并写进报告，它们让范围更准）

• 代理只来自 http_proxy / https_proxy / all_proxy（policy.ts:306-326）；
• loopback 永不走代理（policy.ts:341）。

⇒ 所以这条路径的前置条件是"操作者主动配置了代理"（或写入 $DSH_HOME/.env），且策略在首个插件挂载前安装（install.ts:296-303）。这不是默认态。

5. 建议的报告形态

改写成三段，而不是"bypass"：

1. 可核实的事实：provider.ts:135-136 的代理分支不调用 resolveAddresses（:138），isNonPublicIpLiteral 只判字面量 ⇒ 经代理时，主机名到非公网地址的解析发生在代理侧，本地不再校验；
2. 已知的设计立场（自己先引）：outbound-proxy-policy.md:39 与 :81；network-proxy.md:71 只承诺挡字面量；
3. 请维护者裁定的一点：这条边界（"配置代理 = 信任代理做目标选择"）是否仍要维持？若认为需要收紧，provider.ts:135 是唯一分支点；而要覆盖主机名，就必须在 :136 之前引入额外判定，并与 web-fetch-http/README.md:64 那段"resolves each hostname once … rejects … not public unicast"的表述对齐（否则文档与实现会互相矛盾）。

这个提法把"这是设计"和"这个设计要不要改"分开了 —— 前者你能证明，后者只能由维护者答。这样提，报告不会被一句"design"挡回。

6. ⚠️ 我做了与没做的

• 做了：逐字核对你引的三处（provider.ts、network.ts、policy.ts）＋ 核对设计笔记与用户文档的原文 ＋ 核对相关测试断言。
• 没做：不对"是否存在未知绕过"下任何结论，也不描述任何触发步骤。定性归维护者。
• ref：origin/master = 571902028a（2026-10-14）；dsh-v0.2.1-alpha.3 = 2fbf4359b8，且 git diff 显示 packages/web/web-fetch-http 在两者之间为空 ⇒ 上述行号对两个 ref 同时成立。
• ⚠️ 你说"声称版本 v0.2.1-alpha.1"—— 0.2.1-alpha.3 已于 2026-10-14 发布，建议更新版本口径。