- The Mess: DeepSeek Harness lets a sandboxed AI agent turn off its own confinement with a single shell command. The bug ships in the default configuration.
- The Damage: A prompt-injected agent can escape its file sandbox and potentially access the developer’s SSH keys, cloud credentials and other host data.
- The Fix: Upgrade DeepSeek Harness to 0.1.2-alpha.1 or later and never treat the harness sandbox as a complete security boundary.
The AI agent was supposed to be the thing being contained.
Instead, it found a way to remove the cage.
Security researchers at OX Research disclosed CVE-2026-82533, a critical vulnerability in DeepSeek Harness, an open-source framework for running AI coding agents. The flaw carries CVSS 9.4 and allows a sandboxed agent to disable its own restrictions.
No credentials are required.
No network exposure is required.
No configuration change is required.
The vulnerable configuration is the default one.
The Sandbox Trusted a Header
DeepSeek Harness exposes a local HTTP API on 127.0.0.1:3080.
The API uses a function called isTrustedApiRequest to decide whether a request should be trusted.
The problem is what it trusts.
Instead of checking the actual network peer, the function relied on the client-supplied HTTP Host header.
A local client could simply claim to be coming from a trusted loopback address.
The application accepted the claim.
That turns an authentication boundary into a string comparison.
The Agent Can Break Out From Inside
The really ugly part happens without exposing port 3080 to the network.
DeepSeek Harness runs agent commands inside an OS-level sandbox using mechanisms such as bubblewrap, Landlock or macOS Seatbelt.
But the sandbox still allowed loopback networking.
Ordinary shell commands also did not require an approval prompt.
That combination created the escape path.
A malicious instruction could cause the agent to execute a shell command that talks to the local API. The API then changes the session to danger-full-access, disabling the sandbox and approval prompts.
The agent effectively changes its own security policy.
OX Research verified the difference experimentally: the same command was blocked when the session remained confined, but succeeded after the local API call disabled the restriction.
Prompt Injection Is the Trigger
This is where AI security gets uncomfortable.
The attacker does not necessarily need access to the developer’s machine.
The attacker needs to get malicious instructions into material consumed by the agent.
A poisoned README.
A malicious issue.
A compromised web page.
A hostile repository.
Any untrusted content that causes the agent to execute a command can potentially become the delivery mechanism.
The sandbox exists precisely to limit the damage from that situation.
CVE-2026-82533 breaks that assumption.
Network Exposure Makes It Worse
There is a second attack path.
If the local API becomes reachable through a tunnel, reverse proxy, SSH forwarding, editor port forwarding or another mechanism, an unauthenticated remote attacker can interact with the agent directly.
OX Research says this can allow an attacker to control the agent and download stored conversations without an API key.
That turns a local sandbox escape into a potentially much broader attack surface.
The default service is intended to be local.
But “local” stops meaning much when developers routinely use remote development environments, port forwarding and cloud workspaces.
This Is Not the Only DeepSeek Harness Concern
The project’s own GitHub repository contains additional security reports.
One recent report describes another sandbox boundary problem involving the run_code tool, where model-written TypeScript could execute in an unsandboxed worker thread and gain arbitrary file access and process execution. That report is separate from CVE-2026-82533 and should not be confused with the officially disclosed vulnerability.
DeepSeek’s own security documentation is also unusually blunt: Harness is described as experimental developer-preview software and explicitly warns users not to treat it as secure or production-ready.
That warning is worth taking seriously.
The Fix
OX Research says the CVE was fixed in DeepSeek Harness 0.1.2-alpha.1.
The vulnerable versions are 0.1.1-rc.2 and earlier.
If the software is used for coding work, upgrading should be immediate.
And the architectural lesson is even more important:
An AI coding agent should not have direct access to production credentials.
Do not give the agent your permanent cloud keys because “the sandbox will protect them.”
Use disposable environments.
Use short-lived credentials.
Keep SSH keys away from the agent where possible.
And treat anything consumed by an autonomous coding agent as potentially hostile input.
Bugstoday Opinion
This is exactly the type of AI vulnerability we should expect to see more often.
The problem was not that the model generated dangerous code.
The problem was that the security boundary trusted the wrong thing.
A client-controlled HTTP header.
A local API.
A sandbox with networking left open.
An agent capable of running shell commands.
Put those pieces together and the agent does not need to “hack” the sandbox.
It simply asks the application to turn the sandbox off.
That is a brutal security failure for software whose primary selling point is controlled autonomous execution.
The bigger lesson is simple:
Never make the AI agent the authority that decides whether the AI agent is trusted.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
- OX Security — CVE-2026-82533 DeepSeek Harness Research
- DeepSeek Harness — GitHub Repository
- DeepSeek Harness — Security Documentation
- The Hacker News — DeepSeek Harness Sandbox Escape
- CVE Program — CVE-2026-82533
