Security1 publisher3 min readPublished
One shell command let a DeepSeek Harness agent switch off its own file sandbox
VulnCheck rates CVE-2026-82533 at 9.4. DeepSeek pushed a fix on August 27. The build named in the record never reached npm, and the sandbox itself still confines only writes.
The Watch · Security desk
What happened
- OX Research reported that one shell command to DeepSeek Harness's local web interface set an agent's session to danger-full-access, switching off the file sandbox and the approval prompts.
- The escape worked on a default installation until DeepSeek fixed the tool on August 27, and it needed attacker-supplied text that the agent read to prompt the call.
- OX ran two sessions from identical default settings with the same command: the session that had called the interface wrote outside its workspace, and the other was blocked.
- VulnCheck published CVE-2026-82533 on September 8 at 9.4 out of 10, and its advisory says any caller reaching the interface could also pull a session's entire log without a key.
Compiled by The WatchSomething wrong?How this is made
Why it matters
- exposure On an affected build, any untrusted text an agent merely read could carry the instruction that ended containment, so the exposure sits with anything an agent reads without a human choosing to execute it.
- constraint Because the sandbox confines writes but not reads or network, the tool's own control plane stayed inside the area it was supposed to fence off, which is why network hardening buys nothing on a local install.
- decision Anyone patching by the CVE record's fixed-version field cannot confirm they are covered, so the check has to be made against what the registry actually publishes.
- precedent Desktop apps that bundle their own harness copy move the verification burden onto each vendor's build, and users of those apps cannot answer the version question from npm at all.
Harness asked for consent only when a command requested access wider than the session already held. This command requested nothing. It rewrote the session's own setting, so the tool logged it as ordinary work and ran it [3].
What made that reachable is the shape of the containment. The command-line reference for the affected release says writes stay inside the workspace and temporary folders while reads and network access "are not confined" [8]. The tool also hands the agent's shell the address of its web interface and the current session identifier, so nothing has to be discovered [9]. The control plane sits inside the thing it controls.
The same interface answered callers that were not local. According to OX Research's account, the gate 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" [10]. That header check is what the CVE record describes, and it is the weaker half in practice: the command line refused to bind to all network interfaces, so an outside caller needed the user to have already forwarded or proxied the port through a tunnel, an SSH forward, or an editor [11].
Fourteen days separate the August 13 report from the August 27 fix [5][7][1]. After that the version numbers stop lining up. The CVE record names 0.1.2-alpha.1 as fixed, and that version was never published to npm, which is where the project's own instructions send users [14]. The Hacker News checked the registry on September 9 and found the first published release carrying the authentication change is 0.1.2-alpha.2, three days behind GitHub, so August 30 [15][2]. VulnCheck's record went up on September 8, twelve days after the code changed [4][3]. The install target is 0.1.2-alpha.2 or later; the registry's current release is 0.1.2-rc.1 [16].
The fix gives the interface an identity: a one-time token printed at the startup address, exchanged by the browser for a signed cookie that every subsequent call must carry [17]. That closes the header-spoofing path from another machine, but it does not touch the sandbox. In 0.1.2-rc.1 the reference still says reads and network access are not confined, and the agent's shell still receives the interface address [18]. Whether an agent running inside its workspace can obtain a valid session under the token scheme is unaddressed in the published material, and nothing available describes an in-sandbox block while the tool is running [19].
Operators who cannot upgrade are left with stopping the interface when it is not in use and removing any tunnel, proxy or port forward that reaches it [20]. Binding the listener more tightly does nothing, because the agent is already on the machine [7]. And for anyone running Harness through a third-party desktop app, the version that matters is the one that vendor bundles, not the one on npm [21].
What to watch
- A published test showing whether an in-workspace agent can obtain a valid session cookie under the new token scheme.
- Whether VulnCheck corrects the record's fixed-version field from 0.1.2-alpha.1 to a build that exists on npm.
- Which harness version each third-party desktop build ships, and how quickly those vendors rebase.