# PIR-2026-0060 - DeepSeek Harness: a sandboxed coding agent can turn off its own sandbox with one shell command, because the local control API trusts the HTTP Host header instead of the caller and the sandbox leaves loopback networking open

- `id`: PIR-2026-0060
- `title`: DeepSeek Harness (dsh), DeepSeek's open-source local-first harness for running AI coding agents, exposed an unauthenticated agent-control API on localhost that decided trust from the client-supplied HTTP Host header rather than the real peer. Its OS sandbox blocked file writes but left loopback networking open, so a sandboxed agent could issue a single shell command to that API and switch its own session to danger-full-access - disabling the sandbox and approval prompts without any user confirmation. CVE-2026-82533, CWE-807, CVSS 9.4, fixed in 0.1.2-alpha.1
- `date_occurred`: not applicable - vulnerability disclosure (no confirmed in-the-wild exploitation; proof-of-concept on a default install)
- `date_detected`: 2026-08-13/14 (community members first reported the issue), formalised by OX Research
- `date_disclosed`: 2026-09-08 (CVE-2026-82533 published; OX Research reported to VulnCheck as CNA on 2026-08-24)
- `status`: corroborated (OX Research's disclosure write-up read 2026-09-12, plus The Hacker News' report and the CVE record; product, mechanism, CWE, CVSS, affected/fixed versions and timeline confirmed)

### The agent
- `agent_description`: DeepSeek Harness (dsh) - DeepSeek's open-source, local-first harness for running AI coding agents, with a browser UI and a local HTTP control API on localhost:3080. It runs agents inside an OS sandbox (bubblewrap / Landlock / Seatbelt) that confines filesystem writes. Distinct from CodeWhale/deepseek-tui (PIR-2026-0057).
- `operator_type`: individual developers running the harness locally (affects any deployment on an affected version; the flaw is in the harness, not one operator's config)
- `autonomy_level`: human-on-the-loop by design (an approval-gated coding agent) - the vulnerability is that the agent can remove its own gate
- `model_stack`: DeepSeek models by default; model-agnostic to the flaw - the defect is in the harness's control API and sandbox wiring, not the model
- `harness`: DeepSeek Harness (dsh); affected <= 0.1.1-rc.2; fixed in 0.1.2-alpha.1 (GitHub, 2026-08-27), 0.1.2-alpha.2 (first npm release, 2026-08-30), 0.1.2-rc.1 (current)

### Authority
- `authority_scope`: self-escalation to danger-full-access - a sandboxed agent removes its own filesystem sandbox and approval prompts, gaining unconfined local execution on the developer's machine, from inside the sandbox and with no credentials or network exposure required
- `funds_at_risk_usd`: unknown
- `blast_radius`: one developer machine per affected install; bounded by requiring an agent already running in the harness (a prompt-injected or misaligned agent, or a hostile task), not an external network attacker

### The failure
- `root_cause`: tool-error (the harness makes a security decision from untrusted input - it authorises control-API calls by the client-supplied Host header instead of the peer address, and the sandbox profile leaves loopback networking reachable, so the confined agent can reach the very API that unconfines it; CWE-807, Reliance on Untrusted Inputs in a Security Decision). The same class as PIR-2026-0057 and PIR-2026-0058: an agent harness fails to enforce the boundary it advertises
- `failure_locus`: harness (the coding-agent harness's control API and sandbox configuration; not the model's reasoning and not an external dependency)
- `exploitation_status`: researcher-demonstrated (OX Research demonstrated the escape on a default install and it received a CVE; no confirmed in-the-wild exploitation)
- `mechanism`: DeepSeek Harness runs its agent inside an OS sandbox (bubblewrap/Landlock/Seatbelt) that restricts filesystem writes, and exposes an agent-control API on localhost:3080. That API is unauthenticated: it decides whether a request is trusted from the client-supplied HTTP `Host` header, never verifying the connection's actual peer address. Because the sandbox confines file writes but leaves loopback networking open, the confined agent can reach the API. A single shell command to the control API - with a crafted Host header - switches the agent's own session to `danger-full-access`, which disables the sandbox and turns off approval prompts, without any user confirmation. On shipped defaults, with no network exposure and no credentials, a sandboxed agent escapes its own confinement. CWE-807; CVSS v4.0 base 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). OX Research quote: "a sandboxed AI agent could use a single shell command to call that API and elevate its own session to 'danger-full-access' with approval prompts disabled."
- `adversary_present`: no (disclosed vulnerability; the escaping actor is the sandboxed agent itself - a misaligned or prompt-injected agent, or a hostile task - not a human network adversary)

### Impact
- `severity`: near-miss (a critical sandbox-and-approval self-escape - the entire confinement of the harness defeated by one command - but patched, with no in-the-wild exploitation reported; a proof-of-concept on a default install)
- `direct_loss_usd`: 0 (no confirmed exploitation or loss)
- `indirect_loss_usd`: unknown
- `downtime`: none
- `data_exposure`: none confirmed; the exposed capability is unconfined local code execution on the developer's machine once the agent removes its own sandbox

### Detection and recovery
- `detected_by`: third-party (community reports 2026-08-13/14; OX Research formalised and disclosed)
- `time_to_detect`: reported by the community within days of the affected releases; CVE published 2026-09-08
- `time_to_recover`: fixed in 0.1.2-alpha.1 (2026-08-27), three days after the VulnCheck report
- `remediation`: upgrade to DeepSeek Harness >= 0.1.2-alpha.1 (npm 0.1.2-alpha.2 / current 0.1.2-rc.1). The fix stops trusting the Host header for the trust decision on the control API
- `structural_fix`: the general harness lesson (shared with 0057/0058): a sandbox is only as strong as the paths it leaves open. An agent-control plane must authenticate the actual caller, never a spoofable header, and the sandbox must not leave a network path from the confined agent to the API that can unconfine it. A "danger-full-access" mode that the confined party can enable itself is not a boundary. Approval prompts and sandbox state must be settable only by the human, out of the agent's reach
- `controls_that_worked`: the OS sandbox worked for filesystem writes; it failed to also close the loopback path to the control API, which is what let the agent route around it

### Evidence
- `telemetry_grade`: none (coordinated vulnerability disclosure with a proof-of-concept, not an operated incident with logs)
- `sources`:
  - https://www.ox.security/blog/cve-2026-82533-deepseek-harness-ai-agent-sandbox-escape/ (OX Research's disclosure; product = DeepSeek Harness/dsh, unauthenticated localhost:3080 control API trusting the Host header, sandbox leaves loopback open, single-shell-command escape to danger-full-access, CWE-807, CVSS 9.4, affected <= 0.1.1-rc.2, fixed 0.1.2-alpha.1; disclosure timeline VulnCheck 2026-08-24 / fix 08-27 / CVE 09-08; read 2026-09-12)
  - https://thehackernews.com/2026/09/deepseek-harness-flaw-let-ai-agents.html (The Hacker News, 2026-09; corroborates the mechanism, the danger-full-access mode, the timeline, and that it is distinct from the CodeWhale cluster; read 2026-09-12)
  - https://app.opencve.io/cve/CVE-2026-82533 (CVE record aggregator for CVE-2026-82533, CWE-807)
  - `independence`: medium - OX Research (the discoverer) and The Hacker News (independent reporting) describe the same finding; the CVE record confirms the identifier and CWE. No GHSA advisory existed at publication
- `related`: PIR-2026-0057 (CodeWhale - a DIFFERENT DeepSeek-lineage coding agent, tools bypass the approval gate; explicitly distinct product) and PIR-2026-0058 (n8n - agent tool path skips an access control), the "agent harness fails to enforce its own boundary" family. This record is the sharpest of the three: the agent turns off its own sandbox
- `aiid_incident_id`: unknown (none located as of 2026-09-12)
- `confidence`: high on the identity, mechanism (Host-header trust + open loopback + single-command danger-full-access escape), CWE-807, CVSS 9.4, affected/fixed versions and disclosure timeline, from OX Research's write-up corroborated by The Hacker News and the CVE record; no in-the-wild exploitation claimed

### Verification notes
- 2026-09-12: confirmed against OX Research's disclosure and The Hacker News, cross-checked to CVE-2026-82533 (CWE-807, CVSS 9.4). DISTINCT from the CodeWhale cluster (PIR-2026-0057, CVE-2026-75911/75859/75912/75913) - different product (DeepSeek Harness/dsh vs CodeWhale/deepseek-tui), different mechanism (control-API Host-header trust + sandbox self-disable vs config overrides + git-tool argument injection). Both are DeepSeek-lineage coding agents; do not merge them.
- No GHSA advisory found at publication; cve.org renders via JavaScript so it was read via the OpenCVE aggregator and the OX Research write-up, not the cve.org page.