id: PIR-2026-0060title: 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.1date_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 Researchdate_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)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 gatemodel_stack: DeepSeek models by default; model-agnostic to the flaw - the defect is in the harness's control API and sandbox wiring, not the modelharness: 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_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 requiredfunds_at_risk_usd: unknownblast_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 attackerroot_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 advertisesfailure_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)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: unknowndowntime: nonedata_exposure: none confirmed; the exposed capability is unconfined local code execution on the developer's machine once the agent removes its own sandboxdetected_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-08time_to_recover: fixed in 0.1.2-alpha.1 (2026-08-27), three days after the VulnCheck reportremediation: 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 APIstructural_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 reachcontrols_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 ittelemetry_grade: none (coordinated vulnerability disclosure with a proof-of-concept, not an operated incident with logs)sources: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 publicationrelated: 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 sandboxaiid_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