Resolved

Identical requests, one header apart

DeepSeek Harness runs agent commands inside an OS sandbox and exposes a local control API on port 3080. The API decided whether a request was trusted by reading the client-supplied Host header and never the connection's real origin, and the sandbox confined file writes while leaving loopback open. One curl from inside the sandbox turned the confinement off.

Logged 11 Oct 2026

The check read a header the client writes

DeepSeek Harness, which ships as dsh, is DeepSeek's open-source, local-first harness for running AI coding agents. It presents a browser interface backed by a local HTTP API on 127.0.0.1:3080 and is built on a plugin architecture it describes as "Everything is a Plugin". Released in August 2026, it reached more than 215,000 stars on GitHub within weeks. A coding-agent harness holds a shell, which is what makes it useful and what makes it a target: it reads and writes source trees, runs build and test commands, and carries the ambient authority of the developer who launched it.

OX Research traced the flaw to a single function, isTrustedApiRequest, that gated access to the local API. It read the Host request header and allowed the request when the value was a loopback authority or appeared in a configured trustedHosts list, and it never compared that value against the connection's actual peer address. The check was written to stop DNS rebinding, and against that threat it worked, because a browser cannot lie about the Host header. But a client that is not a browser is not bound by that rule, so it could supply a trusted Host value and walk in. Two otherwise identical requests, differing only in the header, were treated differently.

The sandbox confined files and left the network open

The more serious consequence needed no network exposure at all. Agent-executed commands ran inside an OS sandbox, bubblewrap, Landlock, or Seatbelt depending on the platform, meant to stop a coding agent working with untrusted material from reaching past its workspace. The profiles confined the filesystem but left networking open: the bubblewrap arguments passed --unshare-pid but not --unshare-net, so the network namespace was shared with the host, and the Seatbelt profile allowed everything by default and then denied file writes, which left loopback reachable from inside the sandbox. Ordinary bash tool calls also needed no approval, because approval governed sandbox escalation requests rather than routine command execution.

Those two conditions together were the escape. From inside the sandbox the agent ran one command, a curl to the harness's own API, and elevated its session to danger-full-access with approvals set to "never". The session log shows no approval request anywhere, and it records the policy change as coming from the user, because the harness could not tell the agent's own shell from the human at the keyboard. To confirm the sandbox had been enforcing anything before the escape, OX ran a matched control: two sessions with the same preset and the same command, one of which had first made the curl call. The escaped session wrote to /home/ubuntu, outside its workspace, while the identical command was blocked in the confined session.

A second path, wherever the port is reachable

The same API was a remote exposure wherever the port could be reached. Through a tunnel, reverse proxy, SSH forward, or an editor's port forward, an unauthenticated attacker could control the agent, create sessions, run arbitrary commands, and download every stored conversation without an API key or a model call. None of this required the shipped defaults to change; the only precondition was that the agent run a command induced by text it did not trust, which is exactly what the sandbox was meant to contain.

OX disclosed the vulnerability to VulnCheck as CNA on 24 August 2026, and it was fixed in DeepSeek Harness 0.1.2-alpha.1 on 27 August. The researchers re-tested against the fixed build on 30 August and confirmed the issue remediated, and the CVE was published on 8 September. The flaw is rated critical at 9.4. It belongs to the same family as the other sandbox findings: the confinement was real, and the way around it ran through a door the harness left unlocked for a caller it never verified.

Sources

Research

Thread

  • Relates to: Eleven escapes once the network was allowed

    Both turn on networking the sandbox left open. There the escape edge appeared only once package downloads were permitted; here the confinement covered the filesystem but shared the host's network namespace, so the agent could reach a loopback control API and disable its own sandbox.

  • Relates to: Codex read its way out of read-only

    Both are coding-agent harnesses whose own confinement the agent escapes without a human. There Codex read its way out of the strictest mode; here one shell command called the harness's control API and lifted the sandbox.