
DeepSeek Harness CVE-2026-82533: a sandboxed agent disables its own sandbox with one command
- OrcaNEWOrcaCyber: GLM 5.3 Flash Abliterated2026-10-2794 tok/s
- OrcaNEWOrcaCyber: Qwen3.8 Flash Next Abliterated2026-10-26$0.80 / $1.60 per 1M tokens · 254 tok/s
- OrcaNEWOrcaCyber: MiMo V2.6 Flash Abliterated2026-10-26$0.80 / $1.60 per 1M tokens · 85 tok/s
- MoonshotNEWMoonshotAI: Kimi K3.1 Pro2026-10-2455Intelligence
- OrcaNEWOrcaCyber: DeepSeek V4.1 Flash Abliterated2026-10-23$0.80 / $1.60 per 1M tokens · 108 tok/s
- minimaxNEWMiniMax: M3.1 Flash2026-10-1943Intelligence
- OrcaNEWOrca: OrcaCyber Ultra 1.02026-10-17$5.00 / $10.00 per 1M tokens · 50 tok/s
- deepseekNEWDeepSeek: DeepSeek V4.1 Flash 10172026-10-1745Intelligence
- DeepSeekNEWDeepSeek: DeepSeek V4.1 Flash2026-10-1740Intelligence
- OrcaOrca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 per 1M tokens · 114 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2952Intelligence
- anthropicAnthropic: Claude Sonnet 5.52026-09-2856Intelligence
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 per 1M tokens · 119 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2238Intelligence
- OpenAIOpenAI: GPT-6 Sol2026-09-2248Intelligence
- AnthropicAnthropic: Claude Opus 5.52026-09-2258Intelligence
- xiaomiXiaomi: MiMo-V2.6-Flash2026-09-2138Intelligence
- xiaomiXiaomi: MiMo-V2.6-Pro2026-09-2146Intelligence
- xAIGrok 4.72026-09-2146Intelligence
- OrcaOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $7.50 per 1M tokens · 198 tok/s
VulnCheck published CVE-2026-82533 on 8 September 2026: a critical authentication bypass that let an AI coding agent switch off its own sandbox with one shell command. The software is DeepSeek Harness, DeepSeek's open-source local runtime for coding agents, which the Cloud Security Alliance says drew roughly 215,000 GitHub stars within weeks; everything before 0.1.2-alpha.1 is affected. It judged whether a caller was local from the caller's own Host header, so a request could claim to be loopback. Because its sandbox confined file writes but not loopback networking, a confined agent could call the harness's unauthenticated control API on port 3080 and switch its session to danger-full-access with approvals off. VulnCheck scores it 9.4, critical; no in-the-wild exploitation is claimed. The record is one entry in a public dataset of AI incidents, and the Orca AI Incident Archive holds the full record set, with dates, severity grades and sources for each entry.
The check that asked a request what it was
The vulnerable component is the harness's local agent-control API, the small HTTP service that the web interface and the command line use to drive a running session. According to the Cloud Security Alliance's research note of 10 September 2026, which draws on the write-up by OX Security, the firm that found the flaw, that service listened on 127.0.0.1 port 3080 by default and made its trust decision in a function the note names isTrustedApiRequest. The function read the HTTP Host header and granted access when the value matched a loopback name such as localhost or 127.0.0.1. A Host header is metadata the client writes; it says nothing about where the TCP connection came from. The Hacker News, citing the affected source on 9 September 2026, reports that the check never looked at the connection's origin and that a comment in the same file says the check "is not an auth layer."
That is the whole of CWE-807, reliance on untrusted inputs in a security decision, and it is what VulnCheck's published record describes: a client-supplied loopback Host header accepted in place of validating the actual TCP connection origin.
What turned a bad check into an escape route was the harness handing the agent its own keys. The Hacker News reports that the harness passes the agent's shell the address of the control interface and the identifier of the current session, so a command does not have to discover either. The sandbox, meanwhile, covered one channel and not the other: the command-line reference for the affected release says that under the default setting writes stay inside the workspace and temporary folders, while reads and network access are not confined.

Why approval prompts did not stop it
The harness did have approval prompts, and they were not bypassed so much as inapplicable. The Hacker News reports that in the affected release approval was requested only when a command sought broader access than the session already held. The escalation call sought nothing of the sort; it changed the session's setting. An agent that ran it moved to a mode OX Security calls danger-full-access, with approval prompts set to never, and continued running as the user who had launched the harness, outside the sandbox altogether.
OX Security's evidence for the boundary was a controlled pair. The Hacker News reports that the firm ran two sessions from identical default settings and gave both the same command: the session that made the call wrote to a folder outside its workspace, and the other was blocked.
The second path, and the precondition it needed
The same missing check exposed the harness to callers that were never inside a sandbox at all, but only under a condition the default configuration did not create. The command line refused to bind the API to all network interfaces, so the port was reachable from elsewhere only if a user had already forwarded it — through a tunnel, a reverse proxy, an SSH forward, or an editor's own port-forwarding feature, per The Hacker News; the Cloud Security Alliance note lists the same set. Where that precondition held, VulnCheck's advisory states, a caller without credentials could create sessions, execute arbitrary commands, and exfiltrate stored conversation transcripts. The Hacker News adds that the same interface served a request which downloads a session's entire log.
The sandboxed route needs a different precondition: text the agent will read and act on. The Cloud Security Alliance note describes a confined agent handling an attacker-supplied prompt embedded in a code comment, a README file or issue text. Neither route requires a stolen key, and the note observes that the remote path needs no interaction with the model at all once the port is exposed.
The exposed population is therefore anyone who ran the harness at 0.1.1-rc.2 or earlier on defaults, a set the star count only gestures at. The Hacker News counted more than 216,000 stars on 9 September 2026 and cautioned that a star is a bookmark rather than an installation.
What is established, and what is not
Established, from the CVE record itself: VulnCheck is the numbering authority, it reserved the identifier on 29 August 2026 and published the record on 8 September at 16:59 UTC; the weakness is CWE-807; the affected range is every version before 0.1.2-alpha.1; and the credit goes to Nir Zadok and Moshe Siman Tov Bustan. The two scores the record carries, 9.4 under CVSS 4.0 and 9.6 under CVSS 3.1, come from VulnCheck rather than from a second, independent scorer — NVD lists both metrics with VulnCheck as their source — so they are one assessment expressed in two frameworks, not two assessments agreeing.
Established, from the repository: the fix commit 3e24087, titled "fix(web): authenticate the browser Host API," is dated 24 August 2026, and it adds a browser-auth module together with 210 lines of end-to-end tests for the new flow, according to the GitHub API. The release tagged dsh-v0.1.2-alpha.1 followed on 27 August at 17:06 UTC.
Not established: use. Neither the CVE record, nor VulnCheck's advisory, nor DeepSeek's release notes describe exploitation in the wild, and NVD records exploit maturity as not defined. FIRST's EPSS model gave the flaw a 1.24% probability of exploitation in the following 30 days, at the 68.9th percentile, in the feed dated 27 October 2026. The archive records no real-world harm for this entry and grades it confidence A, well documented, with primary sources agreeing.
The dates, including two reports that came first
Two developers reached the same conclusion before there was a CVE to point at. The Hacker News reports a post on the project's own discussion board on 13 August 2026 showing a process still confined by the sandbox reaching the local interface and switching the session to danger-full-access, with test output, and a second post on 14 August listing the requests that interface accepted without credentials. The second post also noted that the project had no security policy file and no private route for reporting a flaw; The Hacker News checked on 9 September and found the security policy file still missing.
OX Security's timeline puts its report to VulnCheck on 24 August 2026 — the same date GitHub records for the fix commit. The commit message says nothing about the report, and OX Security's public account, as The Hacker News describes it, does not mention the earlier community posts. Whether the two events on 24 August were connected is not something the public record states, and this article does not assume it.
The gap between fix and disclosure is not unusual. The Cloud Security Alliance note records that OX Security confirmed the fix on 30 August, nine days before VulnCheck published the CVE.

Where the fix landed, and where it did not
The GitHub tag and the package registry did not move together, and that is the part worth knowing if you installed the harness the way its instructions suggest. The command-line package, @deepseek-ai/dsh, published 0.1.1-rc.2 on 21 August 2026 and then nothing until 0.1.2-alpha.2 on 30 August. Version 0.1.2-alpha.1, the one the CVE names as the fix, is absent from the registry entirely, so the first installable fixed release trailed the fix by three days. The npm registry metadata was read for this article on 28 October 2026; The Hacker News reported the same gap on 9 September.
The release notes did not frame it as a security release. They list, among routine changes, that the web interface now requires one-time token authentication for network access, with no CVE reference and no security notice, and The Hacker News found no security advisory on the repository's advisory list on 9 September. The mechanism, as the Cloud Security Alliance describes it: the harness prints a one-time token at startup, the browser exchanges that token for a signed cookie, and every subsequent call must present the cookie — trust bound to a secret issued at process start rather than to a claimed network origin.
Third-party builds are the loose end. Desktop wrappers ship their own copy of the harness, so which version a user is running is the wrapper maintainer's choice; The Hacker News found one Windows build pinned to 0.1.1-rc.2 in late August that moved to 0.1.3-alpha.1, which carries the fix, on 6 September.
The sandbox itself is unchanged. Reading the 0.1.2-rc.1 command-line reference, The Hacker News found the same statement that reads and network access are not confined, and found that the agent's shell still receives the interface address. No source in that reporting says whether an agent working inside its workspace can still obtain a valid session under the new scheme, a question the patch's own documentation leaves open.

What the record's sources recommend
• Treat any installation at 0.1.1-rc.2 or earlier as affected regardless of how it was packaged, including a copy embedded in a desktop wrapper.
• Install 0.1.2-alpha.2 or later from npm; the newest version on the registry on 27 October 2026 was 0.2.2-alpha.2.
• If you cannot upgrade, stop the web interface when it is not in use and remove any tunnel, proxy or port forward that reaches port 3080.
• Check whether port 3080 is reachable from anywhere other than loopback, container port forwarding, reverse proxies and SSH tunnels included.
• Log privilege-escalation and approval-mode changes at the harness level, because the attack worked by making an unauthorised escalation look like routine activity.
All five come from the Cloud Security Alliance note and The Hacker News's reporting; the CVE record itself carries no remediation guidance beyond the fixed version.
Why the Cloud Security Alliance reads it as a pattern
The Cloud Security Alliance note places this CVE alongside two other coding-agent containment failures it documented in 2026: GuardFall on 1 July, in which ten of eleven popular open-source coding agents could be induced to run shell commands their guardrails were built to block, and the trust-handoff findings of 22 July, in which a confined agent wrote a file that a trusted component outside the sandbox later executed. The note is explicit that all three come from its own research rather than from an exhaustive survey of the market, and that whether the pattern generalises beyond the agents it examined is not established. What it does argue is that the failures sit at different layers — command guardrails, downstream trust, and now control-plane authentication — and that is why it recommends treating sandbox architecture as a procurement question rather than a satisfied requirement.
DeepSeek's own safety documentation does not contradict that reading. The repository's SAFETY.md states that the software "has not undergone a security audit and must not be treated as secure or production-ready," and that sandboxing, approval prompts and permission controls "do not guarantee isolation or prevent damage." The authentication gap that let an agent walk out through the control API is closed in current builds. The asymmetry that made the walk short — a boundary around writes and nothing around the network — remains a stated limitation of the sandbox rather than a defect the patch set out to fix.
