Skip to content

DeepSeek Harness CVE-2026-82533: a sandboxed AI agent disables its own sandbox with one shell command

Summary

OX Research found and disclosed CVE-2026-82533 (CWE-807 "Reliance on Untrusted Inputs in a Security Decision", CVSS 9.4, vector 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) in DeepSeek Harness (dsh), DeepSeek's open-source, local-first harness for running AI coding agents. On shipped defaults, with no network exposure and no credentials, a sandboxed agent could disable its own confinement with a single shell command — and, wherever the local API port was reachable, an unauthenticated remote attacker could take full control of the agent and export every stored conversation without a key.

DeepSeek Harness is a high-value target for the same reason it is useful: it holds a shell. The agent reads and writes source trees, runs build and test commands, and operates with the ambient authority of the developer who launched it — potentially including access to SSH keys, cloud credentials, package registries, and internal systems reachable from that workstation. A flaw that lets the agent disable its own sandbox removes the control that stands between untrusted input and the developer's machine.

No in-the-wild exploitation or actor attribution is reported; this is a researcher-disclosed, patched-now item.

Tags

What DeepSeek Harness is

  • DeepSeek Harness (dsh) — DeepSeek's open-source, local-first harness for running AI coding agents. Released August 2026; it reached more than 215,000 GitHub stars within weeks, making it one of the most widely starred developer tools of the year.
  • Presents a browser UI backed by a local HTTP API on 127.0.0.1:3080, built on a plugin architecture (tagline: "Everything is a Plugin").
  • Runs agent-executed commands inside an OS sandbox — bubblewrap, Landlock, or Seatbelt, depending on platform — designed to stop a coding agent working with untrusted material from reaching beyond its workspace.

The vulnerability

OX Research traced the flaw to how DeepSeek Harness gated access to its local API. 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 design worked against its intended threat: a browser cannot lie about Host, so a DNS-rebinding request carrying the attacker's domain would be rejected. But request.headers was the only input the function used. A client not subject to browser restrictions — including the agent's own shell, or any process that could open a socket — could simply supply a trusted Host value.

Two conditions then created the escape path:

  1. Loopback was reachable from inside the sandbox. The sandbox profiles confined the filesystem but left networking open:
  2. bubblewrap passed --unshare-pid but not --unshare-net, so the network namespace was shared with the host.
  3. The Seatbelt profile used (allow default) with (deny file-write*) layered on top — file writes were denied, but everything else, including networking, was permitted.
  4. Ordinary bash tool calls did not require approval. Approval governed sandbox-escalation requests, not routine command execution.

From inside the sandbox, the agent ran a single command that called the harness's own unauthenticated API and elevated its session to danger-full-access with approval set to never. Every command after that ran unconfined and without prompting — the sandbox disabled itself. The session log shows no approval/request event anywhere, and the policy change is recorded as source: {kind: 'user'} — the harness could not distinguish the agent's own shell from the human at the keyboard.

OX confirmed the sandbox was actively enforcing its restrictions before the escape with a matched control: two sessions on the same host using the same default preset were given the identical command; the only difference was that one session had first made the curl call that disabled its confinement. The escaped session successfully wrote to /home/ubuntu (outside the session workspace), while the sandbox blocked the identical command in the confined session.

Second attack path: remote, no agent needed

Wherever the port was reachable — through a tunnel, reverse proxy, SSH forward, editor port forward, or a similar mechanism — an unauthenticated remote attacker could directly control the agent and, separately, download every stored conversation without an API key or model call. This path requires no prompt-injection foothold at all.

Affected / fixed

Component Exposure Mitigation
DeepSeek Harness (dsh) 0.1.1-rc.2 and earlier Agent self-sandbox-escape (local) + unauthenticated remote agent-control / conversation exfil (if port reachable) Upgrade to 0.1.2-alpha.1 or later
  • Fixed in DeepSeek Harness 0.1.2-alpha.1 (released Aug 27, 2026); OX re-tested and confirmed the issue remediated on Aug 30, 2026.
  • Responsible-disclosure timeline: Aug 24, 2026 — vulnerability confirmed by execution, report disclosed to VulnCheck (CNA); Aug 27, 2026 — fix released in 0.1.2-alpha.1; Aug 30, 2026 — OX re-tested and confirmed remediated; Sep 8, 2026 — CVE-2026-82533 published.

Durable defender read

  • Treat the local agent API as a network boundary, not a trust assumption. A localhost / 127.0.0.1 API that authenticates by a client-supplied Host header is not loopback-safe: any process that can open a socket to the port (including the agent's own shell, a reverse proxy, an SSH forward, or an editor port-forward) can claim to be loopback. Authenticate on the connection's actual peer address / transport, not on a header a non-browser client can forge.
  • A sandbox that allows loopback but denies file writes does not contain a shell that can make a network call. If the agent can run curl / bash and the control plane is reachable over loopback, the agent can reach its own control plane. Isolate the agent's network namespace (--unshare-net / equivalent) from the host, or block the agent's egress to the control-plane port.
  • Approval-on-escalation is not approval-on-every-command. The escape needed no approval event because routine commands were unapproved and the escalation primitive itself was callable from an ordinary, unapproved command. The control that stops a self-elevation is who may call the control plane, not whether the agent was prompted.
  • A coding-agent harness that holds a shell is a host-execution primitive. Prompt injection that reaches a tool that can run one shell command on a machine holding SSH keys, cloud credentials, and package-registry tokens is host compromise. The standing mitigations are the same as for every agent gateway: untrusted text is data, the control plane is authenticated and peer-checked, and the agent's sandbox is network-isolated.

Defender heuristics

  • Inventory every dsh / DeepSeek Harness deployment and confirm it is at 0.1.2-alpha.1 or later; verify the running version, not the installed artifact.
  • Audit how the local API authenticates. If access is gated by a Host / trustedHosts header check that does not verify the connection's actual peer address, treat it as forgeable and add real transport-level authentication / a peer-address allowlist.
  • Restrict the control-plane port to the intended local caller. Bind to loopback only where required, and block agent-side egress to 127.0.0.1:3080 (or the configured port) so a sandboxed command cannot call the control plane. Prefer --unshare-net (or the platform equivalent) in the agent's sandbox profile.
  • Watch for self-elevation signatures: a session that suddenly runs unconfined after a single command, an approval/request event that is absent where one is expected, and policy changes recorded with source: {kind: 'user'} that no human issued.
  • If the port is reachable beyond loopback (tunnel / reverse proxy / SSH forward / editor port-forward), assume an unauthenticated remote party could have controlled the agent and read stored conversations — rotate any credentials, API keys, SSH keys, and package-registry tokens reachable from that host and treat it as developer-host compromise.

Assessment limits

  • No in-the-wild exploitation or actor attribution is reported; both attack paths are researcher demonstrations (OX Research), reproduced on a default installation with a matched control confirming the sandbox was enforcing before the escape.
  • Affected-version scope is as stated by OX / the CVE record: dsh 0.1.1-rc.2 and earlier, fixed in 0.1.2-alpha.1.
  • The CVSS 9.4 / CVSS 4.0 vector and CWE-807 are from the published advisory; OX frames the flaw as isTrustedApiRequest relying on the client-supplied Host header rather than the connection's actual peer address.

Sources