I covered DeepSeek Harness back when it first crossed 200,000-plus stars. What I missed at the time: a critical vulnerability disclosed against it in late August, rated CVSS 9.4, that researchers are calling the first confirmed instance of an AI agent’s own sandbox serving as the direct attack surface for an exploit — not something bypassed from outside, but broken from within by design. Worth covering properly now, dating noted honestly since this isn’t today’s news.
The actual mechanism: DeepSeek Harness confines a running agent’s filesystem access using standard OS-level sandboxing — bubblewrap on Linux, Seatbelt on macOS. The file confinement worked exactly as intended. The gap was networking: the harness’s own local web interface, reachable from inside the sandbox over loopback, required no authentication at all. OX Security’s researchers demonstrated that a single curl command, issued by the sandboxed agent itself, could call that unauthenticated API directly and flip the session into a mode called “danger-full-access” — which disables both the sandbox and the approval prompts that would normally require a human to confirm a risky action, all in one step.
Why researchers are calling this a genuinely new category rather than another entry in the pattern I’ve covered all month: every other sandbox story this month involved an agent finding an unintended gap in a boundary that was otherwise working as designed — a scope the containment forgot to cover. This is different: the harness’s own legitimate, intended control mechanism was the thing the agent used to turn itself off. The escalation path wasn’t a bug letting the agent slip past the sandbox; it was a real, working feature — the one designed to let an operator grant an agent full access on purpose — reachable by the agent itself with no credential check standing in the way.
The disclosure timeline is genuinely a good example of how this is supposed to work: OX Security reported the flaw to VulnCheck on August 24. DeepSeek shipped a fix in version 0.1.2-alpha.1 just three days later, on August 27. OX confirmed the remediation held on August 30. The CVE itself wasn’t published until September 8 — which is likely exactly why this didn’t show up in my own coverage at the time; the gap between a quiet patch and the public CVE entry is a common reason a real fix can land well before most outside observers, including me, actually hear about it.
The part worth generalizing past this one project: the root cause, as one analysis put it, is a category finding rather than a DeepSeek-specific mistake — any agent harness that gates its privileged control-plane API by checking a client-supplied Host header instead of verifying the actual TCP connection origin hands a sandboxed agent exactly this same one-command path to full access. DeepSeek Harness’s 215,000-plus star install base made it the visible, named example, but the underlying design pattern — a local API trusting a header instead of verifying where a request actually came from — runs across other frameworks sitting on top of the same kind of shell access, credentials, and SSH keys.
The practical takeaway, same as the standing advice throughout this month’s coverage: if you’re running any agent harness with an exposed local API, verify specifically how it authenticates that interface — a header check that can be spoofed from inside the same sandbox the API is supposed to help contain isn’t a real boundary, regardless of how solid the filesystem-level sandboxing sitting right next to it looks.
