DeepSeek Harness Let a Sandboxed Agent Switch Off Its Own Sandbox. Check Your Version, Including Inside Desktop Wrappers

Run DeepSeek Harness 0.1.2-alpha.2 or later, and do not assume a desktop app that bundles the harness has it. DeepSeek shipped the fix as a routine release with no security notice, so nothing in your update feed will tell you this mattered. Our verdict on DeepSeek Harness stays Caution: patched, it is fine for experiments in a disposable VM, not for machines holding credentials or production code.

What happened

OX Research found the flaw and reported it to VulnCheck as CNA on 24 August. VulnCheck published CVE-2026-82533 on 8 September with a CVSS v4 score of 9.4.

• The API. VulnCheck: the harness "grants unauthenticated access to its local HTTP agent-control API" by "accepting a client-supplied loopback Host header in place of validating the actual TCP connection origin."
• The escape. OX Research: the OS sandbox confined the filesystem but left networking open, so loopback was reachable from inside it. A sandboxed agent ran a single command against that API and raised its own session to danger-full-access, with approval prompts disabled.
• Exposed installs. VulnCheck says that when the interface is reachable from outside, a remote attacker can "create sessions, execute arbitrary commands, and exfiltrate stored conversation transcripts without credentials."

Versions

As The Hacker News lists them:

VulnCheck and OX Research name 0.1.2-alpha.1 as the fix, but that build never reached npm. If you install from npm, 0.1.2-alpha.2 is your floor.

Why it matters

The approval prompt and the sandbox are the two controls that let you leave a coding agent running unattended. This bug let the agent turn both off itself, without asking.

• No advisory. The Hacker News reports the fix release listed it among routine changes, as requiring "one-time-token authentication for network access," with no security notice and no CVE mention. The project has no security policy file.
• Earlier warnings. Two developers reported the same escape on DeepSeek's discussion board on 13 and 14 August, with proof-of-concept output, before the CVE existed.
• Wrappers. Third-party desktop builds pin their own copy of the harness. The Hacker News cites one Windows build that pinned 0.1.1-rc.2 in late August and moved to the fixed 0.1.3-alpha.1 only on 6 September.
• Reach. The repository had more than 216,000 stars on 9 September, which The Hacker News rightly calls a count of bookmarks, not installations.

What changes for you

The patch adds one-time-token authentication to the interface: a startup token is exchanged for a signed cookie on every call. That closes this escape. It does not make the sandbox a read boundary. The Hacker News reports that even in the latest release, writes stay inside the workspace and temporary folders while "reads and network access are not confined," and agents are still handed the interface address.

So an upgraded harness is still an agent that can read anything your user account can and talk to the network. That is why our verdict remains Caution rather than moving up.

FAQ

Is 0.1.2-alpha.1 enough? Only if you built from GitHub. It was never published to npm; the first fixed npm release is 0.1.2-alpha.2.

I updated my desktop app. Am I fixed? Not necessarily. Check the harness version the app ships; wrappers pin their own copy and updated on their own schedule.

My interface was only on localhost. Was I exposed? To the sandbox escape, yes: the attacker in that scenario is the agent itself, which runs on your machine. Remote command execution and transcript theft need the interface reachable from outside.