DeepSeek Filed Its 9.4 Sandbox Escape Fix Under Chores

The point of a sandbox is that the thing inside it does not get a vote. DeepSeek Harness — the company's open-source runner for AI coding agents, and one of the most-starred repositories on GitHub at roughly 220,000 stars — shipped for weeks with a sandbox the agent inside could switch off itself, using a single shell command of the kind it was already allowed to run without asking anyone.

The flaw is now CVE-2026-82533, rated 9.4 on the CVSS 4.0 scale. It was found by the OX Research team — Nir Zadok and Moshe Siman Tov Bustan — reported to VulnCheck on August 24, fixed on August 27, and published as a CVE record on September 8. There is no evidence it was ever exploited in the wild, and none of the reporting claims otherwise.

What makes it worth your attention is not the bug. It is everything around the bug: how the fix was labeled, what the project told users in the same breath, and what its security page still says today.

One command, and the cage unlocks

DeepSeek Harness runs agents inside an operating-system sandbox — bubblewrap, Landlock, Seatbelt — that restricts what files the agent can write. It also runs a local web interface on a loopback port, which is how the operator watches and steers the session.

Two design decisions met badly. The first: the function guarding that local API, isTrustedApiRequest(), judged a request by reading the HTTP Host header — a string the client writes — rather than checking the connection's actual peer address. It was built to stop DNS rebinding, where a browser is tricked into aiming at localhost under an attacker's domain. Against a client that can simply type the right header, it stops nothing. The second: the sandbox locked down file writes but left loopback networking open, and routine bash commands did not require approval.

So the agent, which the harness helpfully hands its own interface address and session identifier, could run this, per OX's write-up:

curl -H "Host: 127.0.0.1:3080" http://127.0.0.1:3080/api/sessions/[id]/update -d '{"policy":"danger-full-access","approval":"never"}'

That elevates the live session to danger-full-access and sets approvals to never. No prompt appears, because the setting that would have produced the prompt is the setting being changed. And the harness records the change as originating from the user, not the agent — so an operator scrolling back through the session log sees a permission grant that looks like their own.

OX also found the other half. Where that port had been made reachable over a network — through a tunnel, a reverse proxy, a colleague's convenience — an unauthenticated stranger could reach the same API. The researchers wrote that such an attacker could "directly control the agent and, separately, download every stored conversation without an API key or model call." No credentials, no model spend, no trace in a billing dashboard.

The developers got there first

The Hacker News reports that a community developer described the escape in the project's GitHub discussions on August 13, and a second flagged the unauthenticated interface on August 14 — eleven and ten days before OX filed with VulnCheck.

This desk could not match those two reports to specific threads, but the surrounding record is public. In discussion 1054, filed August 14, a developer works through the access control in source and reports what they find: the privileged settings and credentials methods are pinned to loopback with an empty trust list, and — quoting the code's own comment — "the configuration plane stays loopback-same-origin until a real authentication layer." Their conclusion was not that this was dangerous. It was a feature request: please loosen it, so the settings pages work over a LAN.

That is the tell. The absence of authentication was not hidden. It was written down, in the code, where at least one outside developer read it, understood it, and filed a ticket asking for more of it. The gap between "documented limitation" and "critical vulnerability" was a single unapproved shell command, and nobody had connected the two.

Bullet five of ten, under Chores

The 0.1.2-alpha.1 release notes run to roughly fifty bullet points across four headings: New Features, Improvements, Bug Fixes, Chores. The fix for a 9.4 is not under Bug Fixes. It is the fifth of ten entries under Chores, and it reads, in full: "Require the one-time token in the launch URL when accessing the Web interface over a network."

That sentence is true and almost unreadable as what it is. Nothing marks it as security; no CVE is referenced, because none existed yet. An operator scanning the notes for a reason to upgrade urgently would not find one.

One line above it sits the release's other notable entry, also filed under Chores: "Update the Safety Notice: DeepSeek Harness has not been security-audited, and sandboxing, approvals, and permissions do not guarantee isolation." In the same release in which the project closed a hole that let an agent shut off its own sandbox, it also told users, in a housekeeping bullet, that the sandbox guarantees nothing. Read on August 27 those were two unrelated chores. Read now they are the same sentence twice.

Related The agent opened the folder. The folder opened a shell

The fence that never claimed to be a lock

Read the current source and the architecture is honest about itself. The trust check still lives in api-request-trust.ts, still describes itself as a defense against DNS rebinding and cross-site requests, and still ends its documentation with the line that explains the whole incident: "Network reachability and authentication stay out of scope: binding policy belongs to the webserver config, and this fence is not an auth layer."

The fix did not turn that fence into a lock. It put a lock next to it — a one-time token in the launch URL for network access. The fence is doing the job it always said it was doing. The failure was that it was the only thing standing between a confined agent and its own permission settings.

What is missing is the announcement. As of September 11 the repository's GitHub security advisory list is empty, and the CVE was published by VulnCheck rather than the vendor. The project has moved on quickly — the current release is 0.1.5-rc.2, shipped September 10, four version lines past the fix — and anyone still on 0.1.1-rc.2 or earlier has had no signal that they should stop.

Why this desk is covering a coding tool

Because of what these agents are increasingly asked to hold. This year the industry has shipped agent wallets, agent-to-exchange pipes, and payment rails for autonomous software, all of which assume the harness around the agent is the boundary that holds. A sandbox escape is not interesting when the agent is refactoring a test suite. It is interesting when the same machine has a keystore on disk, an exchange session in memory, and a conversation history that may contain both.

That second detail is the underrated one. The remote half of this flaw let an unauthenticated stranger download stored conversations. People paste things into agent sessions — seed phrases, API keys, signing instructions — that they would never paste into a public form. A conversation archive is a credential archive wearing a different name.