Never Let the Confined Process Dial Home

Never Let the Confined Process Dial Home

On September 8, 2026, VulnCheck disclosed that DeepSeek’s coding-agent harness let the sandboxed agent switch off its own sandbox with a single request to localhost. The bug is patched. The design mistake behind it is still everywhere.

A sandbox is a promise. It says this program can do anything it wants, except the things that matter. On September 8, 2026, VulnCheck published CVE-2026-82533, a CVSS 9.4 flaw in the DeepSeek Harness, and the promise turned out to be conditional. The sandboxed agent could disable its own file sandbox and dismiss the approval prompts that gate its actions by sending a single request to the harness’s own local web interface. No exploit chain. No memory corruption. No cleverness. One request to localhost, and the cage opened from the inside.

The timeline is worth reading closely. Community members flagged the behavior on DeepSeek’s discussion board on August 13 and 14. OX Research, credited to Nir Zadok and Moshe Siman Tov Bustan, reported it to VulnCheck on August 24. DeepSeek pushed a fix to GitHub on August 27 and shipped version 0.1.2-alpha.2 to npm on August 30. Every version at or below 0.1.1-rc.2 was vulnerable. The fix introduced one-time token authentication, with a browser token exchange issuing signed cookies, required on all interface requests.

That is the news peg. Here is the part every explainer skips: nobody writes about the sandbox as a relationship. A sandbox is not a feature of your harness. It is a relationship between two programs, the confined one and the one doing the confining, and the security lives entirely in the separation between them. CVE-2026-82533 is what happens when that separation is a rumor.

Name the Two Bad Options

The first bad option is treating the sandbox as the security model. Ship a harness with a file sandbox and a few approval prompts, check the box, move on to the demo. The interface that manages those controls sits on localhost, unauthenticated, because localhost feels like inside. Localhost is not inside. Localhost is an address, and addresses do not authenticate anyone.

The second bad option is letting the governed party edit the policy. Approval prompts that the agent’s own process can dismiss are not approvals. They are suggestions with extra steps. A policy the constrained process can rewrite is theater, and theater is expensive when the audience is an attacker.

I understand why harnesses get built this way. A local control interface is the fastest route to session management, and trusting loopback is the oldest shortcut in network programming. It works fine right up until the process on the other end of the socket is the process you are trying to constrain. That is the entire threat model of a sandbox, and the shortcut assumed it away.

Follow the Request

Here is the mechanism, precisely. The DeepSeek Harness ran a web interface on the local machine to manage agent sessions: start them, stop them, configure them. That configuration included the file sandbox and the approval prompts. The agent process, the thing being sandboxed, could reach that interface over loopback. Authentication on the interface amounted to trusting the Host header of the incoming request. Nothing verified where the connection actually came from.

The agent had been handed the interface’s address and its session ID as part of normal operation. That was everything the interface needed to hear. So the shape of the exploit was this simple. The exact published writeups describe the shape rather than the literal request path, and the shape is enough, because the design error is the part that transfers to your system:

# the shape of the exploit, not the literal payload
curl -H "Host: localhost" http://127.0.0.1:<control-port>/session/<session-id>/sandbox -X POST -d '{"enabled": false}'

One request. File sandbox off. Approval prompts gone. Full filesystem access for the process you had decided should not have it.

Put plainly, the control plane was reachable from the data plane, and it authenticated callers with a value the caller controls. That is three failures in one design: the boundary was callable, the credential was forgeable, and the address of the control plane was handed to the confined party. Any one of those alone is a finding. Together they are a CVE with a 9.4.

Draw it and the error becomes obvious:

  BEFORE (CVE-2026-82533)

  +-------------------------------+      localhost       +----------------------------------+
  | CONFINED: the agent process   | ------------------> | CONTROL: harness web interface   |
  | file sandbox: ON              |  Host: localhost    | toggles sandbox and prompts      |
  | approval prompts: ON          |  (never verified)   | trusts the Host header           |
  +-------------------------------+                     +----------------------------------+
         ^ the thing being constrained                          ^ the thing doing the constraining
         |                                                        |
         +------------- same trust domain, same machine ----------+
                          the jailer lives inside the jail

A confinement boundary that the confined party can call is not a boundary. That sentence is the whole article, and everything below is just the engineering version of it.

Put the Control Plane Somewhere the Agent Cannot Reach

The fix is not a longer checklist. It is one principle applied everywhere: the supervisor and the supervised must not share a trust domain. Here is what that looks like in practice, in order of how much it actually buys you.

First, never trust the Host header. Not as a fallback, not for local interfaces, not for health checks. The Host header is caller-controlled input wearing a trustworthy name. Every request to a control interface must carry a credential that the caller cannot forge and that the interface actually verifies.

Second, prefer a Unix domain socket and verify the peer, not a bearer value. On a Unix socket the kernel will tell you who is on the other end, and the kernel does not take bribes. SO_PEERCRED gives you the peer’s PID, UID, and GID for free. Compare that against the UID your supervisor runs as, and the agent’s UID never passes, no matter what headers it invents. The check is a dozen lines:

import socket, struct

SUPERVISOR_UID = 1000  # the harness controller's uid; the agent runs as 2001

srv = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)
srv.bind("/run/harness/control.sock")
srv.listen(1)
conn, _ = srv.accept()
pid, uid, gid = struct.unpack("3i", conn.getsockopt(socket.SOL_SOCKET, socket.SO_PEERCRED, 12))
if uid != SUPERVISOR_UID:
    conn.close()  # not the supervisor; no second chances

A few things are worth noting about this snippet. The credential comes from the kernel, not from the request, so there is nothing for the agent to forge. The socket file itself should live in a directory the agent’s UID cannot even list, so the agent never learns the address. And the check happens before a single byte of the request is parsed, which means a malformed request cannot reach a parser bug.

Third, if you must use TCP loopback, the secret has to live where the agent cannot read it. That means a separate UID for the supervisor, a token file at mode 0600 owned by that UID, and tokens that are single-use or short-lived. A bearer token sitting in the agent’s environment variables is the Host header problem with extra steps. The DeepSeek fix got this right: one-time token authentication with a browser-mediated exchange, so the token never sits in a place the agent can read.

Fourth, give the agent no route to the controller at all. Run the supervisor in a separate network namespace, or on a separate host, and let the agent’s sandbox be genuinely unable to address it. Authentication is your second line. Unreachability is your first.

Fifth, make sandbox-off a human action. Disabling confinement should require an out-of-band confirmation, a signed intent from an operator, something the agent cannot produce by construction. If turning off the sandbox is an API call, someone will eventually make that API call, and that someone might be the sandboxed process.

A few things are worth noting about this list. First, each control is small. None of them requires a new product. Second, they compose: unreachability plus peer verification plus human-gated state changes means an attacker needs three independent failures, not one trusted header. Third, the audit is cheap. This week, run one command against every machine where an agent harness runs:

ss -tlnp | awk '$4 ~ /127\.0\.0\.1|::1/ {print}'

For every listener you do not recognize, ask two questions: which UID can reach it, and what happens if the agent process talks to it. If the answer to the second question includes the words “toggle” or “disable,” you have found your own CVE-2026-82533, and it is better that you find it than a discussion-board thread does.

Where This Breaks

Closing the control plane does not stop prompt injection. An agent tricked into misusing legitimate tools is dangerous inside a perfect sandbox. Confinement answers “what can this process touch.” It says nothing about “what will this process choose to do.”

The filesystem is not the only shared surface. Environment variables, the clipboard, DNS, and any mounted socket are all paths the file sandbox never sees. If your threat model ends at file writes, your attacker starts at everything else.

A token the agent can read is not a secret. If the harness passes the control token through the agent’s environment, through a config file the agent can open, or through logs the agent can tail, you have rebuilt the same bug with a longer fuse.

Sandboxing files does not sandbox the network. Without egress controls, the agent can still phone home with whatever it was allowed to read. Read access plus network access is exfiltration access. The sandbox did not fail. It was never asked the right question.

Auto-updating plugins reintroduce unreviewed code inside the boundary. This month’s Plugin4Shell disclosures showed plugin SHA pinning bypassed across four major agent CLIs, with zero-click remote code execution where plugins update in the background. Your sandbox protects exactly the code you let in, and background updates let code in while you are not looking.

This fix is per-harness, and the pattern is industry-wide. September’s disclosure cluster says so: GitSpawn, eight flaws across seven coding agents via malicious .git/config execution, disclosed by Manifold Security on September 1 and 2. Docker’s sandbox escapes, CVE-2026-77179 and CVE-2026-79994, published September 15. This is not one vendor’s bad month. It is what agent runtimes look like before the industry learns the lesson servers learned twenty years ago: the management interface is the most sensitive interface you own.

Build It If, Skip It If

Build it if your agent touches credentials, customer data, production infrastructure, or anything irreversible. If the blast radius includes someone else’s data, control-plane separation is non-negotiable, and “localhost feels safe” is not a control.

Skip it if your agent reads public data and writes to a scratch directory you can delete. A disposable container is enough there, and the afternoon is better spent on the next real risk. Not every agent needs a fortress. The ones that do need an actual one.

The minimal viable version fits in an afternoon. Run the agent as a dedicated UID with no read access to the supervisor’s token file. Bind the control interface to a Unix socket and verify the peer credential on every connection. Log every sandbox-state change to an append-only file the agent cannot touch. That is four changes, each one small, and together they close the exact hole CVE-2026-82533 walked through.

Audit your own harness this week. List its listeners, check which UIDs can reach them, and ask what happens if the confined process dials home. The answer should be nothing. If it is anything else, you already know what to fix.

What is the most exposed control interface you have found running on a machine you manage?

Resources

1. The Hacker News: DeepSeek Harness flaw let AI agents disable their own file sandbox
2. webpro255/awesome-ai-agent-attacks: a sourced timeline of real AI agent security incidents, 2024 to 2026
3. Manifold Security: GitSpawn, eight flaws across seven AI coding agents
4. The CyberSec Guru: Docker sandbox escapes CVE-2026-77179 and CVE-2026-79994