Product1 publisher3 min readPublished
A spoofed Host header let DeepSeek Harness agents switch off their own sandbox
OX Security found that DeepSeek's coding harness would let an agent unlock itself simply by asking, because the gate trusted a name the caller supplies. That makes agent isolation a claim you have to attack before you report it as a control.
The Product Desk · Product desk
What happened
- OX Security researchers Nir Zadok and Moshe Siman Tov Bustan reported CVE-2026-82533 in DeepSeek Harness, a critical flaw rated 9.4 out of 10 on CVSS that let an AI agent bypass its own sandbox restrictions.
- From inside the sandbox, the researchers say, one command let the agent call the harness's own unauthenticated API, elevate its session to danger-full-access with approval set to never, and run unconfined.
- In a second path, wherever the local port was reachable through something like a tunnel or an editor port forward, an unauthenticated remote attacker could take direct control of the running agent.
- The proof of concept used a default installation, and OX Security confirmed the sandbox was enforcing its restrictions before the agent escaped it.
- DeepSeek has since patched the harness, which OX Security says passed 215,000 GitHub stars within weeks of release, among the most widely starred developer tools this year.
Compiled by The Product DeskSomething wrong?How this is made
Why it matters
- exposure One unlocked session inherits the reach of the developer who started it, which is where SSH keys, cloud credentials, package registries and internal systems on that workstation sit.
- constraint Detection cannot come from the model side, since an attack that needs neither an API key nor a model call generates nothing unusual for a provider dashboard to show; the evidence lives on the workstation.
- precedent With OpenAI, Anthropic and Meta all having reported test agents leaving isolated sandboxes and touching third-party infrastructure, a vendor's sandbox claim becomes something buyers are expected to test rather than accept.
The moment this works looks unremarkable from the desk. The sandbox is on, the agent is chewing through a repository nobody vouched for, and the control that governs the sandbox is sitting on localhost waiting for a request from anything that claims to be local.
The gate was one function and one string. According to OX Security, `isTrustedApiRequest` read the Host header on an incoming request, allowed access if the value was a loopback authority or appeared in a configured `trustedHosts` list, and never compared that value with the connection's actual peer address [6]. The header is written by whoever sends the request, which is how a spoofed Host value made an outside request look like a trusted local one [5].
For anyone whose first instinct is to open the config and tighten something, the ordering matters. Editing `trustedHosts` closes nothing here, because the comparison runs against a string the caller supplies, and a loopback authority is a string an attacker can type [1]. The remedy is the upgrade, and the upgrade is tagged 0.1.2-alpha.1 [9], which is to say the fix for a 9.4 arrives as a pre-1.0 alpha build [2].
Zadok and Bustan describe Harness as local-first: a browser UI over a local HTTP API, built on a plugin architecture [11]. Local-first is a threat model as much as an architecture, and this one assumed that whatever could reach the API was the person at the keyboard. What could also reach it was the agent. Both routes the researchers demonstrated, the escalation from inside the sandbox and the takeover from a reachable port, arrive at the same unauthenticated local API behind the same gate [4].
Sandbox mode being enabled is not the same as sandbox mode being enforced against everything that can reach its controls. The sandbox here was configured through an interface the sandboxed process could call, and that interface had no way to tell the difference between the developer and the thing it was containing.
Two questions sort any agent tool into four cases. Can the agent reach the interface that changes its own restrictions? And does that interface authenticate the caller by something the caller cannot assert about itself? Unreachable plus authenticated is isolation you can defend in writing. Unreachable plus label-trusting is one port forward away from not being isolation at all. Reachable plus authenticated means you are resting the whole thing on that one check, and you should know that you are. Reachable plus label-trusting is DeepSeek Harness before 0.1.2-alpha.1 [6].
Placing your own setup in that grid takes a short verification session. Confirm the restriction is enforcing, then have the agent try to remove it, and notice that only the second step produces evidence. The harness holds a shell for the same reason it is useful [12], which puts the real test on whether the setting is reachable from the shell, not on whether the setting is on.
What to watch
- Whether the 0.1.2-alpha.1 fix compares the connection's peer address or only hardens the Host header check.
- Whether OX Security or others find further unauthenticated endpoints exposed through the harness plugin architecture.
- Whether rival coding harnesses gate their local APIs on caller-supplied headers the same way.