AI AgentsAI SecurityVulnerability Management
Every AI coding agent sold to a security team comes with the same reassurance. The agent runs in a sandbox, and anything risky waits for a human to click approve. The sandbox limits what the agent can touch. The approval prompt limits what it can do without asking.
Both of those are policy decisions, and a policy decision is only as strong as the answer to one question: who is allowed to change it?
In DeepSeek Harness, the answer turned out to include the agent.
DeepSeek Harness (dsh) is DeepSeek's open-source, local-first tool for running AI coding agents on a developer's own machine. It launched in August 2026 and passed 215,000 GitHub stars within weeks, which makes it one of the fastest-adopted developer tools of the year.
On September 8, OX Security researchers Nir Zadok and Moshe Siman Tov Bustan published CVE-2026-82533, rated CVSS 9.4 and classed as CWE-807, reliance on untrusted inputs in a security decision. The mechanics are short enough to state in full:
127.0.0.1:3080, with no authentication.isTrustedApiRequest checked the HTTP Host header. According to OX, it "never compared that value with the connection's actual peer address." The Host header is set by whoever sends the request, so anyone can claim to be loopback.curl against the harness's own API and switch its session to danger-full-access, with approval set to never.The sandbox did not break. Nothing had to break. The agent sent a request to the component that decides how sandboxed the agent is, and that component said yes.
The Hacker News adds two details that matter more than the CVSS score. First, the harness handed the agent its own session identifier and the interface's address automatically, so the agent did not have to find the switch. It had already been told where it was. Second, the code's own comment on the Host check said plainly that it was not meant as authentication.
It is tempting to read agent escapes its sandbox as a story about a model scheming its way out. That is not what makes this flaw serious. A coding agent reads whatever is in the repository it was pointed at: READMEs, issue text, dependency docs, test fixtures. As The Hacker News puts it, the escape needed attacker-supplied text that the agent read to prompt it to make the call. Once it has, the agent can write outside its workspace. That means shell profiles, git hooks, SSH configuration and the credential files a developer's machine is full of.
That is a prompt injection with a privilege escalation attached, and the escalation needed no exploit. It needed one HTTP request the agent was fully entitled to send.
There was a remote version too. The API only listened on localhost, but developers forward localhost all the time: SSH tunnels, an editor's remote-development port forwarding, a VPN into a build box. If port 3080 was reachable that way, OX says an unauthenticated attacker could take control of the agent directly and download every stored conversation, with no model API key required. For a coding agent, the conversation history is where people paste stack traces, connection strings and the "just try this token" moment from last Tuesday.
The disclosure timeline is its own finding.
| Date (2026) | What happened |
|---|---|
| Aug 13 | A developer posts the escape, with test output, in DeepSeek's GitHub discussions |
| Aug 14 | A second developer independently posts a list of unauthenticated interface requests |
| Aug 24 | OX confirms the vulnerability and reports it to VulnCheck as CNA |
| Aug 27 | Fix ships in 0.1.2-alpha.1, on GitHub only |
| Aug 30 | 0.1.2-alpha.2 becomes the first npm release carrying the fix; OX re-tests and confirms remediation |
| Sep 3 | 0.1.2-rc.1, the current stable build, carries the fix |
| Sep 8 | CVE-2026-82533 published |
Eleven days passed between the first public post and the formal report. The second report also noted that the project had no security policy file and no private way to report a flaw, which may be why the first warnings went into a public discussion thread. The project's own safety notice tells users not to rely on the tool as their only security control for untrusted work.
That notice is honest, and it is also the opposite of what most teams assume when they approve a tool with a sandbox toggle in its settings. A project can pick up 216,000 stars faster than it can set up a security inbox. The tool reached developer laptops at the speed of npm install. Its security process ran at the speed of a volunteer checking GitHub discussions.
DeepSeek's fix adds a one-time token, printed at startup, which the browser exchanges for a signed cookie that every later interface call must carry. That closes this CVE, and upgrading is the first thing to do.
The fix answers "was this request authenticated?" It does not, on its own, answer the question that applies to every agent harness on the market: can the thing being confined reach, read or edit the thing that decides how confined it is? That might be a control API on loopback, a token in a file the agent can read, or a config file inside the workspace that sets the approval mode. The shape of the failure is the same each time.
This is not the same failure as the ones we have covered recently, even though all of them involve a sandbox:
DeepSeek Harness is a fourth pattern. The isolation worked, the prompt existed, and the confined process could still turn both off through an approved channel.
Anywhere else in an organisation this has a name. A payment clerk who can approve their own payment, an engineer who can merge their own change to production without review, a user who can raise their own access level: auditors call these segregation of duties failures. They count as failures even when nobody has abused them yet, because the control only works if the requester and the approver are different parties. An agent approval mode the agent can set is the same failure, running on a developer's laptop.
3080 on developer machines and build hosts. Then look for the ways it gets exposed without anyone meaning to: SSH -L forwards, editor remote-development port forwarding, tunnels and proxies. Close the web interface when it is not in use.danger-full-access that they did not set themselves, and check shell profiles, git hooks and SSH config on those machines for changes nobody made on purpose.The boundary first. Obiguard does not run on the developer's laptop and does not sandbox shell commands. A curl to 127.0.0.1:3080 and a file written outside the workspace never touch our gateway, and nothing we sell would have stopped this escape. Upgrading the harness is the fix.
What Obiguard Governance AI does is make sure that the part of an agent's authority you control centrally is not self-service.
Policy is bound to the credential and resolved at the gateway. When an agent's model traffic goes through Governance AI, the gateway looks up the agent's policy set from its Access Key on the server side. Nothing in the request selects, loosens or removes it. There is no header an agent can send to give itself full access. An agent that has been talked out of its local sandbox still reaches the model under exactly the rules it had before: jailbreak and prompt-injection detection, PII redaction, block-lists and the criteria your team wrote. Rules can be set to fail closed. If the evaluation service cannot return a verdict, the request is refused rather than passed through unchecked.
Changing the rules takes two people. Organisation-wide Controls in Governance AI go through an approval workflow with segregation of duties built in: the person who submits a control cannot approve it. That is exactly the property DeepSeek Harness lacked, applied to the policy that governs your agents: the party asking for a change is not the party that grants it.
The steering is on record. A prompt injection that tells an agent to escalate has to reach the model first, inside a prompt. Governance AI writes every prompt, response, tool call and policy decision to the Audit Log, and sends violations flagged for human judgement to the Review Queue. If one of your agents does something nobody asked for, you can look up the instruction it was following instead of rebuilding it from a laptop.
None of this replaces a harness that keeps its own switches out of the agent's reach. It means the controls that do live centrally were designed on the assumption that the agent will try to reach them.
The DeepSeek Harness sandbox did exactly what it was built to do. It stopped file writes. It did not stop the agent from asking for the file-write restriction to be lifted, and the component that received that request had no way to tell the agent apart from the developer.
That is going to keep happening, in other tools, because it is the easy way to build them. The harness needs a control plane. The control plane has to listen somewhere. Localhost feels private, and the agent is running locally too.
So when you evaluate an agent tool, don't stop at does it have a sandbox? Ask who is allowed to turn the sandbox off, and does that list include the agent?
Explore Governance AI or talk to us about putting your agents' policy somewhere they cannot reach.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →