DeepSeek Harness let a sandboxed agent switch off its own sandbox

DeepSeek Harness runs an agent's shell commands inside an operating-system sandbox so that work on untrusted files cannot write outside the agent's workspace. VulnCheck scored the flaw 9.4 out of 10 on CVSS 4.0 and classified it as CWE-807, reliance on untrusted input in a security decision. The local control API checked only the Host header supplied by a client, not where the request originated.

The Hacker News reviewed OX Research's account of the exploit. A single command from inside the sandbox could call the API, set the session to danger-full-access, and disable the sandbox and approval prompts without showing a prompt. The agent's shell already receives the API address and session ID required for the call.

DeepSeek fixed the authentication gap on GitHub on August 27. The first npm release with the fix shipped August 30. On September 9, The Hacker News checked the npm registry and found that installations pinned to the earlier release had remained exposed for those three days. Two developers had posted working demonstrations of the same escape to DeepSeek's discussion board in mid-August, weeks before OX Research's report produced a CVE.

The fix does not change the sandbox's scope. The project's command-line reference states that under the default setting, "reads and network access are not confined." Its safety notice warns that sandboxing and approval prompts "do not guarantee isolation or prevent damage" and should not be the only security control.

Why it matters: DeepSeek Harness had more than 216,000 GitHub stars on September 9, though stars count bookmarks rather than installations. Operators should check what a harness's sandbox actually covers instead of relying on the presence of a sandbox setting. In this case, one local API call could disable it.