DeepSeek Harness CVE-2026-82533: Sandbox Escape at CVSS 9.4

Any engineer who has run an AI coding agent on a laptop with live SSH keys already knows the threat model is thin. CVE-2026-82533 makes it thinner. A sandboxed agent inside DeepSeek Harness can disable its own confinement with a single shell command, on shipped defaults, with no network exposure and no credentials. The CVSS 4.0 score is 9.4.

The Numbers

Start with the score. 9.4 on CVSS 4.0 is not a "patch it next sprint" number. The 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, tells you everything: network-reachable, low complexity, no privileges required, high impact across confidentiality, integrity, and availability, and high impact on the subsequent system too. The only mitigating factor is user interaction, which in an agent context means "the agent runs a command the attacker asked it to run." That is the entire job of a coding agent.

Then the reach. DeepSeek Harness, or dsh, is a local-first harness for running AI coding agents. Released in August 2026, it pulled in more than 215,000 GitHub stars within weeks, which the disclosure describes as one of the most widely starred developer tools of the year. That is not a niche research project. That is a tool sitting on tens of thousands of developer workstations, running with the ambient authority of whoever launched it.

The disclosure timeline is tight and clean. As OX Security reported, researchers Nir Zadok and Moshe Siman Tov Bustan confirmed the vulnerability by execution and disclosed it to VulnCheck as CNA on August 24, 2026. A fix landed in DeepSeek Harness 0.1.2-alpha.1 on August 27. OX Research re-tested on August 30 and confirmed remediation. CVE-2026-82533 was published on September 8, 2026. Three days from disclosure to patch on an alpha-versioned tool is fast. Three days is also longer than it takes a motivated attacker to weaponise a public writeup.

The CWE classification, CWE-807 Reliance on Untrusted Inputs in a Security Decision, is the tell. This is not a novel class of bug. This is the same category of mistake that has been rediscovered in web frameworks for two decades. What is new is the blast radius: the untrusted input is a header, and the security decision it gates is "can this caller disable the sandbox?"

What's Actually New

The technical mechanism is worth reading carefully, because it will be repeated in other harnesses. DeepSeek Harness exposes its agent-control API on 127.0.0.1:3080 without authentication. A single function, isTrustedApiRequest, reads the Host request header and allows access if the value is a loopback authority or appears in a configured trustedHosts list. It never compares that value to the connection's actual peer address.

The comment on that function makes clear it was designed to stop DNS rebinding. Against a browser, it works. Browsers cannot lie about Host. Against a shell inside the sandbox, it does not work at all, because a raw HTTP client can set any Host value it wants. The sandbox itself, whether bubblewrap on Linux, Landlock, or Seatbelt on macOS, restricted file writes but left loopback networking open. On Linux the bubblewrap arguments passed --unshare-pid but not --unshare-net. On macOS the Seatbelt profile used (allow default) with (deny file-write*) layered on top. The sandbox was file-focused. The API was network-reachable from inside the sandbox. The two never met.

The exploit chain is one shell call. Ordinary bash tool calls required no approval. The agent hits its own local API, elevates the session to danger-full-access with approval prompts disabled, and every subsequent command runs unconfined and unprompted. The policy change was recorded in the session log as source: {kind: 'user'}, and no approval or request event appeared anywhere after the escape. The harness could not distinguish the agent's own shell from the human at the keyboard. That is the genuinely new part.

My take: the interesting failure here is not the header check. It is the architectural decision to have a privileged control API and a sandboxed shell share a network namespace and speak to each other with no cryptographic binding. Production incidents I've seen in the fintech space that look like this usually involve internal service meshes trusting an X-Forwarded-For header. Same shape, different clothes.

What's Priced In for Security Teams

Anyone who has spent time on OWASP categories in the last five years already assumed AI coding agents were a soft target. The ambient authority argument is well understood: the agent holds a shell, reads and writes source trees, and can reach SSH keys, cloud credentials, package registries, and internal systems from the developer's workstation. That risk was priced in the day teams started running these tools.

What was not priced in, at least not honestly, is that the sandbox meant to bound that authority is often theatre. Teams I've worked with treat "it runs in a sandbox" as a sufficient answer to the security review. This CVE is a clean counterexample. The sandbox was actively enforcing file-write restrictions at the moment of escape. The proof of concept confirmed that. It just did not enforce the thing that mattered, which was "the agent cannot talk to its own control plane."

The second attack path is where CISOs should feel something. If the port is reachable through a tunnel, reverse proxy, SSH forward, or editor port forward, an unauthenticated remote attacker can take full control of the agent and separately export every stored conversation without an API key or model call. Every developer who has ever run ssh -L to share a local service with a teammate just became a threat model. Every editor with a port-forwarding extension too. That is not priced in.

Contrarian View

The consensus reading of this CVE will be "AI agents are dangerous, add more sandboxing." I think that is the wrong lesson. More sandbox layers on top of a broken trust boundary just move the goalposts. The uncomfortable read: the real problem is that agent harnesses are being designed with the same casual localhost-is-safe assumption that produced a decade of CSRF and DNS-rebinding bugs, and the industry is rushing to ship these tools before that assumption gets audited.

There is also a counter-argument to the severity framing. UI:P in the vector means user interaction is required. In practice, "the agent runs attacker-controlled text" is the default operating mode of a coding agent working on a real repo with real dependencies. So UI:P is doing no defensive work here. If anything, the 9.4 score understates the operational risk for teams running these agents against pull requests from external contributors or against dependency trees pulled from public registries. This should probably be tracked against the CISA KEV catalog the moment exploitation in the wild is observed.

Key Takeaways

• Upgrade DeepSeek Harness to 0.1.2-alpha.1 or later immediately. Anything shipped before August 27, 2026 is vulnerable on defaults.
• Audit any local agent-control API for peer-address verification. Never trust the Host header as an authentication signal. Bind privileged endpoints to a Unix socket with filesystem permissions, or require a per-session token the sandboxed shell cannot read.
• Treat loopback networking as reachable from inside your sandbox unless you explicitly unshare the network namespace. Check your bubblewrap flags for --unshare-net. Check your Seatbelt profile for network rules, not just file-write* denies.
• Assume any dev tool listening on localhost is one ssh -L away from being remote. Inventory port forwards and editor extensions on developer machines the same way you inventory VPN tunnels.
• Log policy changes with the actual initiator, not source: {kind: 'user'}. If your session log cannot tell an agent's shell from a human's keyboard, your audit trail is fiction.

The fix shipped in three days. The design pattern that produced the bug ships in every new agent harness this quarter. Patch the CVE. Then go read your own harness's trust boundary code before someone else does.