DeepSeek Harness QVD-2026-57410 Explained: How a Forged Host Header Can Lead to RCE

QVD-2026-57410 is a reported critical vulnerability in DeepSeek Harness (DSH) 0.1.1-rc.2. QiAnXin-linked reports describe it as an unauthenticated remote-code-execution flaw with a CVSS 3.0 score of 9.8. The central issue is that DSH’s /api trust decision can rely on a client-controlled HTTP Host header—an unsafe substitute for authentication. 1924

The practical risk depends heavily on deployment. DeepSeek’s documented web command starts the interface on 127.0.0.1:3080 by default, which limits direct remote access. Exposure becomes materially more dangerous when that service is published on a non-loopback interface or forwarded through Docker, a reverse proxy, a tunnel, VPN, LAN, or ingress. 1118

How the Host-header bypass works

The affected design attempts to distinguish local requests from remote ones through the request’s host information. But the Host header is supplied by the requester and can be forged. An attacker who can reach the service can therefore present a local-looking host value and cause the /api layer to treat the request as trusted. Reports describe this as a bypass of DSH’s loopback-style trust boundary. 1924

At a high level, the reported attack chain is:

1. Reach an exposed DSH web or management endpoint.
2. Send a request with a forged local-style Host header.
3. Bypass the /api restriction that is intended to protect internal operations.
4. Invoke restricted RPC functionality.
5. Register or use an attacker-controlled model-provider route.
6. Drive DSH’s agent capabilities to execute commands on the host. 1920

This is why the flaw is more serious than a simple routing or information-disclosure bug: the bypass reaches functionality designed to operate an AI agent with system-level capabilities.

Why the bug can become remote code execution

DeepSeek describes Harness as experimental developer-preview software that has not undergone a security audit. Its safety notice warns that the project can execute model-generated code and commands and access the network, processes, credentials, and files made available to it. 4

The LLM subsystem also supports provider registration and model discovery, including a discoverModels remote operation. 23 In the reported exploit chain, an attacker-controlled provider can be used to supply the input needed to reach the agent’s command-execution capabilities. 19

A successful exploit would not automatically grant root access. Commands would run with the permissions of the DSH service process. Those permissions may nevertheless be sufficient to read or modify accessible files, use available credentials or API keys, start processes, alter application data, or make outbound network connections. The ultimate impact depends on how the service is deployed—for example, whether it has excessive filesystem access, privileged container settings, a mounted Docker socket, or access to cloud credentials. The supplied reporting does not establish that every deployment is automatically a full host takeover.

Which deployments are most exposed?

Operators should treat the following configurations as urgent review targets:

• DSH bound to 0.0.0.0 or another non-loopback address.
• Docker or another container runtime publishing port 3080 beyond the local host.
• A reverse proxy forwarding the management API to the Internet or an untrusted LAN.
• A tunnel, VPN, or ingress that makes the service reachable to users who are not strongly authenticated.
• Proxy configurations that accept arbitrary client Host values or pass them upstream unchanged.

A service being “internal” is not, by itself, an authorization control. Any attacker who can reach the endpoint and influence the relevant request headers may be able to attempt the bypass.

Public PoC, CVE status, and exploitation evidence

Multiple reports state that proof-of-concept material or technical details for QVD-2026-57410 are public. 192027 That increases the urgency of containment, but public PoC availability should not be confused with evidence that a particular installation has been compromised.

The supplied reporting says there was no observed in-the-wild exploitation and no evidence linking the issue to a known threat actor or campaign at the time of disclosure. 1924 That is a limited snapshot, not a guarantee of safety. Exposed instances should still be investigated for suspicious requests, unexpected provider registrations, new processes, and unusual outbound connections.

QVD-2026-57410 is a QVD identifier, not a CVE identifier. The similarly numbered CVE-2026-57410 refers to an unrelated MailerPress privilege-escalation vulnerability, according to the NVD entry. 17

Recommended response for operators

1. Remove network exposure first

Stop publishing the DSH management and API service to the public Internet. Bind it to loopback or a dedicated management network, and use a controlled VPN or bastion for remote administration.

2. Restrict access at every network layer

Apply firewall, cloud security-group, container-network, and reverse-proxy rules that allow only explicitly trusted sources. Do not rely on an internal route or a “local-looking” header as proof of identity.

3. Validate and overwrite proxy headers

Reject unexpected Host values at the edge proxy. Where proxying is required, overwrite the upstream Host header with a known fixed value rather than blindly forwarding the client’s value. Treat forwarded client-IP headers as trustworthy only when they come from a controlled proxy.

4. Add authentication independent of Host

Protect management and internal RPC operations with real authentication and authorization, such as a strongly authenticated gateway, mTLS, and per-operation access controls. Host-header validation can help with routing; it must never be the only identity check.

5. Reduce provider-discovery and outbound risk

Disable or restrict llm.discoverModels when it is not needed. Where model-provider discovery is required, allowlist provider endpoints and apply outbound egress controls. Blocking access to sensitive internal and cloud-metadata destinations can reduce the impact of a provider-discovery path being abused as a server-side request primitive. The DSH LLM documentation confirms that provider registration and model discovery are exposed capabilities. 23

6. Verify the fix through official release information

The supplied sources identify 0.1.1-rc.2 as the affected version and show later release activity, but they do not establish that a particular later build fixes this vulnerability. Check DeepSeek’s current release notes and security advisories for an explicitly confirmed remediation before treating an upgrade as sufficient. The project’s own safety notice continues to warn that Harness is experimental and not production-ready. 410

7. Hunt and rotate if exposure existed

Review reverse-proxy and DSH logs for anomalous /api requests, local-style forged host values, unexpected model-provider registrations, process launches, file changes, and outbound connections. Rotate credentials accessible to the DSH process. If there is evidence of command execution or persistence, isolate and rebuild the affected host or container rather than assuming that restarting the service removed the compromise.