DeepSeek Harness Sandbox Bypass Let Agent Escape

A security bug in DeepSeek Harness, the open-source tool for running AI coding agents on a developer's machine, allowed a sandboxed agent to turn off its own file sandbox with a single command. The tool normally runs an agent's commands inside an operating-system sandbox, a protective boundary meant to keep an agent working on untrusted files from writing outside its assigned workspace. On a default installation, however, that agent could call the tool's own local web interface on the same machine, change its session to a mode called danger-full-access, and then run commands outside the sandbox without any approval prompt. This worked until DeepSeek fixed the tool on August 27, and it required attacker-supplied text that the agent read to prompt it to make the call. The flaw is tracked as CVE-2026-82533. VulnCheck, which assigned the identifier, published the record on September 8 and rated the flaw 9.4 out of 10.

OX Research, the security firm that reported the flaw, said one shell command was enough. The command invoked the tool's local interface and set the agent's session to danger-full-access, which turns off the sandbox and stops approval prompts. Ordinary commands did not need approval to begin with. Approval was applied only when a command requested broader access than the session already had, and this call did not request broader access; it changed the session's setting instead. OX said it checked that the sandbox had been working before the escape. It ran two sessions from the same default settings and gave both the same command. The session that had made the call wrote to a folder outside its workspace, and the other session was blocked.

The sandbox only covers files. The command-line reference for the affected release says that under the default setting, writes stay inside the workspace and temporary folders, while 'reads and network access are not confined.' That left the tool's own interface reachable from inside the sandbox. The tool also provides the agent's shell with the address of that interface and the current session's identifier, so the agent does not have to look for them. The interface had no authentication. In the affected release, the check that determined whether a request could reach it read the request's Host header and never looked at where the connection originated. A comment in that file says the check 'is not an auth layer.' That check is what the CVE record describes. Because it trusted a header the client supplies, a machine outside could claim to be local and drive the agent. The tool's command line refused to listen on all network interfaces, so reaching it from outside needed the user to have forwarded or proxied the port through a tunnel, an SSH forward, or an editor. The same interface served a request to download a session's entire log. VulnCheck's advisory states that a caller who reaches the interface could retrieve all stored conversations without a key.

Versions 0.1.1-rc.2 and earlier are affected. The record names 0.1.2-alpha.1 as the fixed version, but that version was never published to the npm registry, the online package catalog where the project's own instructions send users. The first fixed release on npm was 0.1.2-alpha.2, published on August 30. The current npm release, 0.1.2-rc.1, carries the fix and was published on September 3. The Hacker News checked the registry on September 9 and found that the first published release with the authentication change is 0.1.2-alpha.2, three days after the fix was pushed to GitHub. Users should install 0.1.2-alpha.2 or later. If they installed the harness through a third-party desktop app, they should check which version of the harness it ships. If they cannot upgrade, they should stop the web interface when not using it and remove any tunnel, proxy, or port forward that reaches it. No source reviewed for this article offers a way to stop the escape from inside the sandbox on a default local installation while the tool is running. The August 13 report says limiting the address the tool listens on does not help, because the agent is already on the same machine.

The fix gives the interface an identity check. The tool now prints a one-time token at its startup address; the browser exchanges that token for a signed cookie, and every call to the interface requires the cookie. What the fix does not change is the sandbox. In 0.1.2-rc.1, the same reference still says that reads and network access are not confined, and the agent's shell still receives the interface address. No source addresses whether an agent running inside its workspace can still obtain a valid session under the new scheme. Third-party desktop builds ship their own copy of the harness, and which copy they ship is the wrapper maintainer's choice. One Windows build pinned 0.1.1-rc.2 in late August and moved to 0.1.3-alpha.1, which carries the fix, on September 6. Anyone who installed the harness through a wrapper should check which version it ships.

A coding-agent harness is worth attacking because it holds a shell. DeepSeek Harness runs an agent's commands under the account that started it. The project's own safety notice states that the software has not undergone a security audit and that sandboxing and approval prompts 'do not guarantee isolation or prevent damage.' It tells users not to rely on the tool as their only security control for untrusted work. The repository had more than 216,000 stars on September 9, a count of accounts that bookmarked it rather than installations. Researchers have repeatedly found coding agents escaping their sandboxes this year, including a set of flaws in which a repository's own configuration caused agents to run attacker code outside their sandboxes.

Community reports described the same escape in August on DeepSeek's own discussion board. On August 13, one developer posted a report showing a process still held by the sandbox reaching the local interface and then switching the session to danger-full-access, with test output. On August 14, another developer posted a report listing the requests the interface accepted without any credentials. That second report also noted that the project had no security policy file and no private way to report a flaw. The project still has no security policy file. OX Research reported the flaw to VulnCheck on August 24, by its own timeline, and VulnCheck credits Nir Zadok and Moshe Siman Tov Bustan. OX's post does not mention the earlier reports. The Hacker News checked the repository's advisory list on September 9 and found no security advisory published. The release that carried the fix lists it among routine changes, as removing an old transport and requiring 'one-time-token authentication for network access,' with no security notice and no mention of the CVE.

For teams that run coding agents or host applications in production, AEU-I offers security-first IT, infrastructure and consulting, a useful place to start when reviewing how tools like D