Trust No One, Not Even ‘localhost’

1. Event Summary

In August 2026, Qi An Xin Threat Intelligence Center disclosed a remote code execution vulnerability in DeepSeek Harness (DSH), tracked as QVD‑2026‑57410. The CVSS 3.0 score is 9.8 (Critical), with low attack complexity, no required privileges, and no user interaction.

Proof‑of‑concept code was published on GitHub within days. As of this writing, no official patched release exists; a component‑level hotfix has been issued but does not address the root cause.

2. How the Vulnerability Works

The DSH management API (under /api) has no authentication – no tokens, no cookies, no TLS client certificates. The only access control is a check that looks at the HTTP Host header:

python

if request.headers.get('Host') not in ('127.0.0.1', 'localhost'):
    return 403

This works in a browser because of the same‑origin policy, but any non‑browser client (e.g., curl, Python scripts) can set the Host header to any value. Attackers can forge Host: 127.0.0.1 and send requests directly to the API.

A concrete attack command (replace 203.0.113.5 with the target IP, port 3000 open):

bash

curl -X POST http://203.0.113.5:3000/api/rpc \
  -H "Host: 127.0.0.1" \
  -H "Content-Type: application/json" \
  -d '{"method":"agent.exec","params":{"command":"id > /tmp/pwned"}}'

If the DSH process runs as root, the command writes to the system. Even as a non‑privileged user, it can read environment variables, configuration files, and private keys. Public PoC toolkits include interactive shells and reverse‑shell payloads, making exploitation trivial.

3. Who Is Affected

Any deployment that exposes the management port (default 3000) to the public internet is at risk. Common misconfigurations include:

• Docker -p 0.0.0.0:3000:3000

• Cloud security group rules allowing inbound TCP/3000 from 0.0.0.0/0

• Reverse proxies (Nginx, Caddy) that do not add authentication for /api and do not filter the Host header

Internet scans show hundreds of such instances remain exposed, including research labs and AI startups. No large‑scale exploitation has been observed yet, but scanning traffic increased threefold within 72 hours after the PoC release.

4. Root Causes

Design assumption mismatch. DSH was originally built as a local development tool, binding to 127.0.0.1 by default. The official documentation does not forbid binding to 0.0.0.0, and many users do so for team collaboration or plugin integration. Once exposed, the “trusted local network” assumption collapses.

Missing authentication and sandbox. In GitHub Issue #853, a researcher noted: “The DSH web UI does not have an authentication layer – this is by design.” That design works only when the service is never reachable from outside. Plugins can invoke arbitrary system commands with the same privileges as the main process; there is no permission model. A malicious plugin can compromise the host.

5. Mitigation (Priority Order)

Until an official patch is released, take these steps:

Priority 1 – Immediate
Remove the management port from public security groups. Allow access only from trusted internal IP ranges (e.g., 10.0.0.0/8) or localhost. In cloud consoles, delete the inbound rule 0.0.0.0/0:3000.

Priority 2 – If external access is required
Add strict Host header validation and an authentication layer at the reverse proxy. Example Nginx configuration:

nginx

location /api/ {
    if ($http_host !~* "^your-trusted-domain.com$") { return 403; }
    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:3000;
}

Priority 3 – Monitoring
Log and alert on external requests with a forged Host: 127.0.0.1 targeting /api/rpc or /llm.discoverModels.

Priority 4 – Stay updated
Watch the official DeepSeek release page. When a stable version >0.1.1 is published, test it in staging and upgrade.

6. Status of the “Fixed” Version

The component update (dsh-web-ui-all) released in mid‑August 2026 strengthens the Host‑header check but does not introduce real authentication. Security researchers agree that a full fix requires redesigning the API permission model – a bigger task. For now, network isolation is the only reliable defence.