A sandboxed coding agent can switch off its own sandbox in DeepSeek Harness

What was found

On September 8, 2026, VulnCheck published CVE-2026-82533, a critical authentication bypass in DeepSeek Harness. A CVE is a public catalog number for a security flaw. The harness is DeepSeek's open-source runtime for coding agents on your own computer, and the Cloud Security Alliance (CSA) said it gathered about 215,000 GitHub stars within weeks.

As OrcaRouter reported, the flaw lets an agent that is supposed to be confined turn off its own confinement with a single shell command. Every version before 0.1.2-alpha.1 is affected. The sources do not claim anyone has exploited it in real attacks.

A check that read the wrong thing

The weak point is the harness's local control interface, a small web service that the browser UI and command line use to steer a running session. By default it listens on port 3080 of the local machine. According to the CSA, which drew on a report from OX Security (the firm that found the bug), a function decides whether a request is trusted by reading the HTTP Host header and approving names like localhost.

A Host header is just text the sender writes. It says nothing about where the network connection actually came from, so a request can simply claim to be local. The Hacker News reported that the check never looks at the connection's origin, and that a code comment in the same file admits it is not an authentication layer. This is a known weakness class, CWE-807: relying on untrusted input to make a security decision.

Why the fence and the prompts didn't help

Two design choices turned a weak check into an escape route. First, the harness hands the agent's shell the control interface's address and the current session's ID, so the command needs no searching. Second, the sandbox limited where files could be written but left network access to the local machine open. A confined agent could therefore call the control API directly.

With that call, the session switched to a mode OX Security calls danger-full-access, with approval prompts set to never. The agent then ran as the user who launched the harness, outside the sandbox. The approval prompts did not fire because, per The Hacker News, they only trigger when a command asks for broader access than the session already has. This call changed the session's settings instead.

OX Security ran a controlled comparison. Two sessions with identical default settings received the same command. The one that made the call wrote to a folder outside its workspace, and the other was blocked.

A second path, and who is exposed

The same missing check opens a route for callers who were never inside the sandbox, but only under one condition. The command line refuses to bind the API to all network interfaces, so someone must already have forwarded the port through a tunnel, reverse proxy, SSH forwarding or an editor's port-forwarding feature. If so, VulnCheck says an unauthenticated caller can create sessions, run arbitrary commands and steal stored conversation records.

The sandboxed path needs different groundwork: text the agent will read and act on. The CSA note describes attacker-written instructions hidden in code comments, README files or issue text. Neither path needs a stolen key, and the remote one needs no interaction with the AI model at all.

The exposed group is anyone running 0.1.1-rc.2 or earlier with default settings. Star counts only hint at its size, since The Hacker News counted more than 216,000 on September 9 and noted that stars are bookmarks, not installs.

The fix, and what remains unclear

The repository's fix, commit 3e24087, is dated August 24, 2026 and is titled as authenticating the browser Host API. It adds a browser authentication module and 210 lines of end-to-end tests. Under the new scheme, the harness prints a one-time token at startup, the browser trades it for a signed cookie, and later calls must present that cookie. Trust now rests on a secret issued at launch, not on a claimed origin.

Getting the fix is messier than it should be. The CVE names 0.1.2-alpha.1 as the fixed version, but that version is missing from the package registry, so the first installable fix was 0.1.2-alpha.2, published August 30. The release notes mention the new token requirement but give no CVE reference, and The Hacker News found no security advisory in the repository on September 9. Desktop wrappers that bundle their own copy of the harness depend on their maintainers. One Windows build stayed on 0.1.1-rc.2 until it moved to 0.1.3-alpha.1 on September 6.

The sandbox design itself did not change: writes are fenced while reads and network access are not. DeepSeek's own safety document says the software has not been security audited and its protections are not guaranteed. Whether an agent working inside its workspace can still obtain a valid session under the new scheme is not answered in the sources.