"is not an auth layer," a comment in DeepSeek Harness's code read — a terse admission that helped enable a serious local-escape flaw now tracked as CVE-2026-82533.
How the sandbox escape worked
DeepSeek Harness runs AI coding agents' commands inside an operating-system sandbox intended to keep writes confined to a workspace. Researchers at OX Research and community members found that an agent could disable that protection with a single shell command: the agent called DeepSeek Harness's own web interface on the same machine and set its session to a mode named danger-full-access. That change turned off the sandbox and stopped approval prompts. OX Research reported that one shell command was sufficient; in test runs the session that made the call was able to write outside its workspace while a parallel session without the call remained blocked.
Technical weaknesses that enabled the escape
The exploit depended on several concrete design choices in the affected release. The harness' command-line reference for the affected release says that, under default settings, writes stay inside the workspace and temporary folders while "reads and network access are not confined." The tool provides the agent's shell with two helpful pieces of information: the address of the local web interface and the session identifier. The interface itself required no authentication in the affected release.
Critically, the check that determined whether a request could reach the interface examined the HTTP Host header supplied by the client and never inspected where the connection originated. A comment in that file — "is not an auth layer" — acknowledged the check's limits. VulnCheck's advisory notes that because the code trusted a header the client sets, a machine outside could claim to be local and drive the agent. The harness refused to listen on all interfaces by default, so remote access required the user to have forwarded or proxied the port through a tunnel, SSH forward, or an editor.
VulnCheck also stated that the same interface served a request that could download a session's entire log: a caller who reached the interface could retrieve all stored conversations without a key.
The cyber insurance questionnaire just landed. Now what?
SOC 2, HIPAA, insurance renewals - someone has to own security strategy. Nubivance provides fractional CISO leadership without the full-time salary.
Get a security leadAffected versions, the fix, and interim mitigations
- 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 where the project directs users. The Hacker News found that 0.1.2-alpha.2 — published three days after the fix was pushed to GitHub — is the first registry release with the authentication change.
- The advisory guidance: install 0.1.2-alpha.2 or later; check which harness version third-party desktop apps ship; if you cannot upgrade, stop the web interface when not using it and remove any tunnel, proxy, or port forward that reaches it.
The code change implementing the fix gives the interface an identity check: at startup the tool prints a one-time token at its startup address; a browser exchanges that token for a signed cookie, and every subsequent call to the interface requires that cookie. What the fix does not change is the sandbox's scope — reads and network access remain unconstrained in 0.1.2-rc.1 — and the agent's shell still receives the interface address. 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 sources also do not address whether an agent running inside its workspace can still obtain a valid session under the new scheme.
Community disclosure and repository signals
Two developers described the same escape on DeepSeek's discussion board in mid-August: one posted on August 13 showing a process still held by the sandbox reaching the local interface and switching the session to danger-full-access; a second on August 14 listed interface requests accepted without credentials and noted the project lacked a security policy file and a private reporting channel. OX Research reported the flaw to VulnCheck on August 24; DeepSeek pushed a fix on August 27. VulnCheck published the record on September 8 and rated the flaw 9.4 out of 10, assigning CVE-2026-82533.
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 the change among routine updates — removing an old transport and requiring "one-time-token authentication for network access" — with no security notice or mention of the CVE. The repository had more than 216,000 stars on September 9.
What this means for technologists, third-party builders, and end users
- Technologists and security teams should treat the harness like any local service that exposes an agent shell: verify the installed harness version and apply 0.1.2-alpha.2 or later; if an upgrade is not possible, stop the web interface and remove any tunneling or port forwards that expose it.
- Third-party desktop app maintainers must check which harness release their wrapper ships. The source notes 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.
- End users should heed DeepSeek's own safety notice: the software has not undergone a security audit and sandboxing plus approval prompts "do not guarantee isolation or prevent damage." The sandbox covers files only; reads and network activity were not confined in the affected release.
DeepSeek Harness's flaw combined a powerful capability — giving an agent a shell on the developer's account — with an interface that could be driven from inside the sandbox. The patch replaces a header-trusting check with one-time-token exchange and signed cookies; it does not, however, broaden the sandbox or change that the agent sees the interface address. For operators and wrapper maintainers, the immediate task is clear: confirm your harness build, update to a published release that carries the one-time-token change, and eliminate any exposed tunnels until you can.
