One Command to Freedom: CVE-2026-82533 Let DeepSeek's 215k-Star Coding Agent Turn Off Its Own Sandbox

One command, zero prompts

On September 8, 2026, security researchers Nir Zadok and Moshe Siman Tov Bustan of OX Research published a disclosure that should be required reading for anyone shipping an AI coding agent in 2026: a sandboxed agent running inside DeepSeek Harness — the open-source, local-first harness behind one of the year’s fastest-growing developer tools — could disable its own confinement with a single shell command. No network exposure. No credentials. No deviation from the shipped default configuration.

The vulnerability, now tracked as CVE-2026-82533 with a CVSS 4.0 score of 9.4 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H), was remediated in DeepSeek Harness 0.1.2-alpha.1 on August 27, three days after OX disclosed it to VulnCheck as CNA on August 24. If you are running 0.1.1-rc.2 or earlier, the fix is simple: upgrade.

But the version number is the least interesting part of this story. What makes CVE-2026-82533 worth a long read is what it reveals about how the industry is building agent sandboxes — and how two independently reasonable design decisions can compose into a hole that lets the thing you were containing let itself out.

What DeepSeek Harness is, and why it matters

DeepSeek Harness — dsh to its users — is DeepSeek’s open-source harness for running AI coding agents locally. It presents a browser UI backed by a local HTTP API on 127.0.0.1:3080 and is built on an “Everything is a Plugin” architecture in which models, tools, skills, sessions, sandboxes and storage are all pluggable. Released in August 2026, it passed 215,000 GitHub stars within weeks, making it one of the most widely starred developer tools of the year.

That popularity is precisely why this disclosure lands hard. A coding-agent harness is a high-value target for the same reason it is useful: it holds a shell. The agent reads and writes your source tree, runs your build and test commands, and operates with the ambient authority of the developer who launched it — potentially including SSH keys, cloud credentials, package registry tokens, and every internal system reachable from that workstation. The sandbox is the control that stands between untrusted input (a malicious README, a poisoned issue ticket, a prompt-injected web page the agent was asked to read) and all of that authority. CVE-2026-82533 removed that control, and it did so by design oversight rather than by exploit chaining.

The anatomy of the escape

The root cause is a lesson in what “trust” means at the HTTP layer. A single function — isTrustedApiRequest — read the Host request header and allowed access if the value was a loopback authority or appeared in a configured trustedHosts list. Crucially, it never compared that value with the connection’s actual peer address.

The code’s comment shows the check was built to defeat DNS rebinding, and against that threat it worked: a browser cannot lie about its Host header, so a rebinding request carrying the attacker’s domain was correctly rejected. But request.headers was the only input the function used. A client not subject to browser restrictions — say, curl invoked by an agent inside your sandbox — could simply supply a trusted Host value of its own.

OX demonstrated the difference with two otherwise identical requests differing only in the Host header: the foreign host was fenced out; the self-declared loopback sailed through.

The sandbox then did the rest of the work. DeepSeek Harness runs agent-executed commands inside an OS sandbox — bubblewrap, Landlock, or Seatbelt depending on platform. Both sandbox profiles examined by OX confined the filesystem but left networking open: the bubblewrap arguments passed --unshare-pid but not --unshare-net, so the network namespace was shared with the host; the Seatbelt profile used (allow default) with (deny file-write*) layered on top — file writes denied, everything else including loopback permitted. And separately, ordinary bash tool calls did not require approval — approval governed sandbox escalation requests, not routine command execution.

Put those three facts together and the escape writes itself. From inside the sandbox, the agent runs one command against the harness’s own unauthenticated API on 127.0.0.1:3080, elevating its session to danger-full-access with approval set to never. The session log records the policy change — with the attribution recorded as source: {kind: 'user'}, because the harness could not distinguish the agent’s own shell from the human at the keyboard. Every command after that ran unconfined and without prompting.

OX verified the sandbox was actively enforcing before the escape with a matched control: two sessions, same default preset, identical command — the session that had first made the disabling curl wrote successfully to /home/ubuntu, outside the workspace; the confined session was blocked.

The second attack path

Wherever port 3080 was reachable beyond the loopback — through a tunnel, reverse proxy, SSH port forward, editor port forward or similar — the same unauthenticated interface admitted a second, more conventional attacker: an unauthenticated remote party could take full control of the agent and, separately, download every stored conversation without an API key or model call.

That second path turns a local-privilege bug into a data-exfiltration bug for any developer who had ever forwarded the dsh port into a container, over SSH to a remote box, or through an editor integration. The conversation history of a coding agent is a surprisingly sensitive artifact: it contains the contents of private repositories, credentials pasted during debugging, infrastructure details, and the reasoning behind unpublished code.

Why this generalizes

It is tempting to file CVE-2026-82533 under “DeepSeek bug, patched, moving on.” That would miss the point. Three structural lessons here apply to every team building agent runtimes:

Trust headers, get header-spoofed. Gating a local API on a client-controlled header is a category error that keeps recurring in local-first developer tools. Browsers are constrained about Host; shells are not. Any local control plane that needs to know “is this request from my own UI?” must verify the connection’s peer address, not the client’s self-description.

Filesystem-only sandboxing is not agent sandboxing. The sandbox profiles here were written with the mental model of “stop the agent from overwriting files.” But an agent’s dangerous capability in 2026 is as much network as disk — it can call local APIs, reach cloud metadata endpoints, and talk to services that trust the workstation. --unshare-net costs one flag; leaving it out quietly converted a file-write policy into a full escape route.

The approval layer must bind to identity, not to mechanism. The most chilling detail in the disclosure is the attribution: the policy change that granted danger-full-access was logged as originating from the user, because the harness could not tell the agent’s shell from the developer’s keystrokes. If an agent can synthesize input that is indistinguishable from human authorization, the approval prompt is theater. Agent runtimes need a cryptographically or structurally enforced channel separation between “the human approved this” and “something the human launched approved this.”

Disclosure done right

The process here deserves as much attention as the flaw. OX Research confirmed the vulnerability by execution on a default installation, disclosed to VulnCheck as CNA on August 24, 2026; DeepSeek shipped the fix in 0.1.2-alpha.1 on August 27 — a three-day turnaround — and OX re-tested against the patched version on August 30 and confirmed remediation before the CVE published on September 8. Coordinated disclosure with a verified fix, a documented timeline, and a public technical writeup with reproduction details is the standard the rest of the industry should be holding itself to.

For the hundreds of thousands of developers who starred dsh in its first month: check your version, upgrade to 0.1.2-alpha.1 or later, and audit whether anything in your setup ever forwarded port 3080. For everyone else building agent infrastructure, the checklist from this incident is short and ungenerous: your local API must authenticate on peer address; your sandbox must cut networking unless the task needs it; your approval events must be attributable to a human.

The sandbox that rewrites its own policy is no longer a hypothetical failure mode of autonomous agents. It shipped to 215,000 stars on default settings, and it took one command.