A Sandboxed AI Agent Could Switch Off Its Own Sandbox — and DeepSeek Harness Trusted It

The security control most agentic coding tools lean on is the sandbox. Let the model read the repo, let it run builds, let it churn through a test suite — but fence the filesystem so that a poisoned README or a malicious dependency can't reach past the workspace. That fence is the reason it's considered acceptable to point an autonomous agent at code you didn't write.

In DeepSeek Harness, the fence had a gate, and the agent was handed the key on startup.

What the vulnerability is

DeepSeek Harness — dsh — is DeepSeek's open-source, local-first harness for running AI coding agents. It presents a browser interface backed by a local HTTP control API bound to 127.0.0.1:3080, and it wraps agent-executed commands in an operating-system sandbox: bubblewrap or Landlock on Linux, Seatbelt on macOS.

OX Research found that an agent confined by that sandbox could disable its own confinement with a single shell command, on stock defaults, with no network exposure and no credentials. The issue is now tracked as CVE-2026-82533, classified as CWE-807 (reliance on untrusted inputs in a security decision), and rated 9.4 (critical) by VulnCheck, which acted as CNA. Credit goes to OX researchers Nir Zadok and Moshe Siman Tov Bustan.

The one precondition is the one that matters: the agent has to be nudged into running the command by attacker-supplied text it encounters while working. Which is precisely the scenario the sandbox exists to survive.

Why the sandbox didn't stop it

Three design decisions, each defensible alone, combined into an escape hatch.

The sandbox only ever covered files. The bubblewrap invocation unshared the PID namespace but not the network namespace. The Seatbelt profile allowed everything by default and then layered a file-write denial on top. Loopback networking stayed wide open from inside the sandbox — and the project documented this openly, noting that under the default policy, reads and network access aren't confined.

Routine commands never needed approval. The approval prompt was wired to sandbox escalation requests, not to ordinary execution. A shell command that quietly rewrote the session's policy wasn't asking for more access in the way the approval logic recognised, so nothing prompted.

The harness told the agent where to find its own control plane. Environment variables carrying the web UI's canonical loopback URL and the current session ID were injected into the model's shell on every call, by design, so the agent could reference the interface it was running under. No port scanning, no guessing required.

Put together: the agent could reach the control API, the control API would change the session's permission mode, and nothing in between asked a human.

OX confirmed the sandbox had genuinely been enforcing beforehand by running a matched control — two sessions from the same default preset, given the same command, differing only in whether one had made the escalation call first. The escaped session wrote to a directory outside its workspace. The confined one was blocked.

One detail in the session log deserves more attention than it has received: the policy change was recorded as originating from the user. The harness had no way to tell its own agent's shell apart from the person at the keyboard.

The trust check that wasn't

The gate on the local API was a single function that decided whether a request could be trusted. It read the Host header, checked whether the value looked like a loopback address or appeared in a configured allow-list, and let the request through if so. It never compared that value against the connection's actual peer address.

The check was written to stop DNS rebinding, and against that threat it worked — a browser can't forge Host. But anything that isn't a browser can set the header to whatever it likes. A comment in the file said outright that this was not an authentication layer. It was nonetheless the only thing standing in front of the API.

That gives a second, remote attack path. Wherever the port had been made reachable — an SSH forward, a tunnel, a reverse proxy, an editor's automatic port forwarding — an unauthenticated attacker could drive the agent directly and, separately, pull down every stored conversation without a key or an API call.

The part that got reported first, and went further

Three weeks before the CVE was published, a developer posting as mxym filed a detailed reproduction on the harness's own GitHub discussion board, dated August 13. Written in Chinese and running to fifteen numbered sections, it identified the same root cause and demonstrated it against a real Landlock-confined child process rather than inferring it from source.

It also documented two things the CVE write-up does not.

The first is an approval-hijacking path. Pending approval requests were broadcast to every subscriber on the event stream — and replayed to any client that connected afterwards, a behaviour the project's own test suite explicitly covered. A confined background process could therefore subscribe, wait for the approval prompt meant for the human, and answer it itself. The endpoint that accepted the answer validated only that the responder knew the request's correlation identifiers, not that it was the browser.

The second is worse, and appears to be unaddressed in public coverage so far. Settings writes were among the privileged operations gated by the same loopback trust. The default web-search provider exposes its endpoint URL as a writable setting, and resolves the API credential fresh on every search. Chained, that means a sandboxed agent could repoint the search endpoint at a server it controls, then trigger a search — sending the provider API key, in both the x-api-key and bearer authorization headers, along with the query text, to that server. The author's summary of the root cause is hard to improve on: reachability over loopback is not the same thing as authority from a human.

The same post noted that the project had no security policy file and no private channel for reporting flaws. At the time of writing it still does not, which is why a report of this severity ended up on a public discussion board in the first place.

Versions, and a gap worth knowing about

Everything up to and including 0.1.1-rc.2 is affected. The fix — an identity check that mints a one-time token at startup, exchanges it for a signed cookie in the browser, and requires that cookie on every call — shipped in 0.1.2-alpha.1 on August 27.

That version was never published to npm, which is where the project's own install instructions point. Checking the registry directly shows the package jumping straight from 0.1.1-rc.2 to 0.1.2-alpha.2:

So there is a three-day window in which the fix existed publicly on GitHub but could not be installed the documented way — and a nine-day stretch between the last vulnerable npm build and the first patched one. The advisory names 0.1.2-alpha.1 as the fixed version, which is accurate but not actionable for anyone installing from the registry.

The release notes for the patched version list the change among routine work, describing it as requiring one-time-token authentication for network access. No security advisory has been published in the repository, and the CVE is not referenced there.

What to do

• Install 0.1.2-alpha.2 or later. The registry's latest tag currently resolves to 0.1.2-rc.1, so a plain install gets you a fixed build.
• Check what your wrapper ships. Third-party desktop builds bundle their own copy of the harness, and the pinned version is the wrapper maintainer's choice, not DeepSeek's.
• If you can't upgrade immediately, kill the exposure you control. Shut the web interface down when it isn't in use and remove any tunnel, proxy or port forward that reaches it. Note that this only closes the remote path — no public source describes a way to block the local escape on a default installation while the tool is running, and restricting the listen address doesn't help, because the agent is already on the same machine.
• If the port was ever exposed beyond your machine, treat stored sessions as read. Conversation export needed no credential.

The broader point

What makes a coding-agent harness worth attacking is exactly what makes it useful: it holds a shell, and it runs with the full ambient authority of the developer who launched it — SSH keys, cloud credentials, package registry tokens, whatever that workstation can reach.

DeepSeek's own safety notice is candid about this. It states that the software has not had a security audit and that sandboxing and approval prompts do not guarantee isolation or prevent damage, and it tells users not to treat the tool as their only control when handling untrusted work. That is worth reading as a live constraint rather than boilerplate.

The wider pattern is the one to watch. A run of findings this year has shown agents crossing their own confinement boundaries, and the common thread is rarely a broken kernel primitive. It is an authority question: some component decides the caller is trusted, using a signal the caller can produce for itself. Landlock did its job here. The gate in front of the API is what let the agent walk around it.

Vulnerability details: VulnCheck advisory for CVE-2026-82533. Technical analysis: OX Research. Version data verified against the npm registry. Earlier community reproduction: deepseek-harness discussion #250.