OX Research found and disclosed a critical vulnerability in DeepSeek Harness, DeepSeek’s open-source AI coding-agent harness, that allowed a sandboxed AI agent to disable its own confinement with a single shell command – on shipped defaults, with no network exposure and no credentials.
Vulnerability Details
CVE: CVE-2026-82533
CWE: CWE-807 Reliance on Untrusted Inputs in a Security Decision
CVSS: 9.4
CVSS 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
Description: DeepSeek Harness exposed its agent-control API on a local HTTP port without authentication, relying solely on the client-supplied ‘Host’ request header to determine whether a request was trusted rather than verifying the connection’s actual peer address. Because the product’s OS sandbox restricted file writes but left loopback networking open, a sandboxed agent could use a single shell command to call that API and elevate its own session to ‘danger-full-access’ with approval prompts disabled — effectively disabling its own sandbox on the shipped default configuration. If the port was exposed to a network, the same interface also allowed an unauthenticated remote attacker to take full control of the agent and export every stored conversation without a key.
Overview
OX Research discovered that a confined AI agent running inside DeepSeek Harness could disable its own sandbox.
DeepSeek Harness runs agent-executed commands inside an OS sandbox – bubblewrap, Landlock, or Seatbelt, depending on the platform – designed to prevent a coding agent working with untrusted material from reaching beyond its workspace. But OX researchers found that the sandbox restricted file writes while leaving loopback networking open, and ordinary shell calls required no approval.
That meant a single command was enough. From inside the sandbox, the agent could call the harness’s own unauthenticated API and elevate its session to ‘danger-full-access’ with approval set to ‘never’. Every command after that ran unconfined and without prompting.
No network exposure, credentials, or changes from the shipped defaults were required. The only precondition was that the agent execute a command induced by attacker-supplied text — precisely the kind of untrusted input the sandbox exists to contain.
In our proof of concept, OX Research demonstrated the vulnerability on a default installation and verified that the sandbox was actively enforcing its restrictions before the escape. We also demonstrated a second attack path: wherever the port was reachable — through a tunnel, reverse proxy, SSH forward, editor port forward, or similar mechanism — an unauthenticated remote attacker could directly control the agent and, separately, download every stored conversation without an API key or model call.
OX Research disclosed the vulnerability, now tracked as CVE-2026-82533, to VulnCheck as CNA on Aug. 24. The issue was remediated in DeepSeek Harness 0.1.2-alpha.1.
About DeepSeek Harness
DeepSeek Harness (‘dsh’) is DeepSeek’s open-source, local-first harness for running AI coding agents. It presents a browser UI backed by a local HTTP API on ‘127.0.0.1:3080’ and is built on a plugin architecture — its own tagline is “Everything is a Plugin.” Released in 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.
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 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.
DeepSeek Harness ships with an OS sandbox specifically to bound that authority when an agent is working with material it should not trust. A vulnerability that allows the agent to disable that sandbox therefore removes the control designed to stand between untrusted input and the developer’s machine.
Responsible Disclosure Timeline
- Aug 24, 2026 – Vulnerability confirmed by execution; report disclosed to VulnCheck as CNA
- Aug 27, 2026 – Fix released in DeepSeek Harness 0.1.2-alpha.1
- Aug 30, 2026 – OX Research re-tested against 0.1.2-alpha.1 and confirmed the issue remediated
- Sep 8, 2026 – CVE-2026-82533 published
Technical Details
OX Research traced the vulnerability to the way 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 comment makes clear what the check was designed to prevent, and against that threat it worked: 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 could simply supply a trusted ‘Host’ value.
The flaw can be demonstrated with two otherwise identical requests, differing only in the ‘Host’ header:
The fence worked as designed against a foreign ‘Host’. What it could not do was distinguish a legitimate loopback request from a client simply claiming to be loopback.
The Sandbox Rewrites Itself
The more serious consequence required no network exposure at all.
Agent-executed commands ran inside an OS sandbox. The sandbox profiles show exactly what that confinement covered:
Both profiles 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 were denied, but everything else, including networking, was permitted. Loopback was therefore reachable from inside the sandbox.
Separately, ordinary ‘bash’ tool calls did not require approval. Approval governed sandbox escalation requests, not routine command execution.
Together, these two conditions created the escape path. From inside the sandbox, the agent ran a single command:
The session log records what followed:
No ‘approval/request’ event appears anywhere in the log. The confined command ran without a prompt and lifted its own confinement. The attribution is also notable: 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.
To confirm that the sandbox had been actively enforcing its restrictions before the escape, OX ran a matched control on the same host. We created two sessions using the same default preset and gave them the identical command. The only difference was that one session had first made the ‘curl’ call that disabled its confinement.
‘/home/ubuntu’ sits outside the session workspace. The escaped session successfully wrote there, while the sandbox blocked the identical command in the confined session.session.
Affected Versions
| Affected Product(s) | Version(s) |
| DeepSeek Harness (`dsh`) | 0.1.1-rc.2 and earlier |
Remediation
To resolve this issue, upgrading to DeepSeek Harness 0.1.2-alpha.1 or later is recommended.
