DeepSeek Harness let a sandboxed attacker run arbitrary commands simply by changing the HTTP Host header to 127.0.0.1, which scores 9.4 on the CVSS scale. The flaw shows how a single misplaced trust decision can turn a protective boundary into an open backdoor.

How the bug slipped in

The vulnerable code lives in a single function that reads the request’s Host header and, if the value equals the loopback address, treats the request as coming from the local machine.

An attacker who can execute code inside the sandbox doesn’t need a sophisticated payload. By sending one HTTP request with Host: 127.0.0.1, the backend believes the call originates from the host itself and skips all security prompts, rate-limit checks, and command-validation steps. The result: unrestricted command execution with no further interaction required.

Why trusting headers is dangerous

Headers are plain-text strings supplied by the caller. Whether the field is named Host, X-Forwarded-For, or any custom name, the client can set it to any value it wishes. The only reliable source of truth about where a connection really came from is the transport layer – the socket’s source IP address that the operating system records when the TCP handshake completes.

When an application decides to trust a header without confirming that a known, correctly-configured proxy injected it, it hands an attacker the keys to the kingdom. The DeepSeek Harness bug is a textbook example of this misstep.

Real-world impact: the shell.online example

The open-source shell.online project, which offers a web-based terminal, recently documented the same pitfall. It uses a configuration flag called TRUST_PROXY:

  • TRUST_PROXY = 0 – the app ignores the X-Forwarded-For header and relies on the socket’s remote address. This prevents a client from forging an IP address to evade rate limits or masquerade as a trusted user.
  • TRUST_PROXY = 1 – the app trusts the X-Forwarded-For header as the client’s identity. If the service is not behind an actual proxy that sanitises this header, an attacker can supply a fresh IP address on every request, effectively resetting any per-IP throttling.

The DeepSeek bug mirrors this scenario: the code trusted Host as if a proxy set it, yet the service could be accessed directly.

What developers need to do now

  1. Audit every place you read client-supplied headers. Identify which headers you treat as authoritative (e.g., Host, X-Forwarded-For, X-Real-IP) and verify that a trusted proxy is guaranteed to rewrite them before they reach your application.
  2. Tie security decisions to the socket address whenever possible. Use the OS-provided source IP for authentication, rate-limiting, and access-control checks.
  3. Enable proxy-trust flags only when a correctly configured reverse proxy sits in front of the service. If you run the app directly, keep those flags disabled.
  4. Document the required deployment topology in your project’s README or deployment guide, so users who self-host know about the proxy-trust requirement.
  5. Run static-analysis or code-review tools that flag direct use of headers for security decisions without accompanying proxy-validation logic.

What to watch next

Communities that ship self-hosted web services are likely to revisit their own proxy-trust settings after this incident.

The core lesson is stark: never let a piece of text that anyone on the internet can write dictate the security posture of your system. Trust the network layer, not the request layer.