DeepSeek Harness is DeepSeek's open-source runtime for its AI coding agent — the component that actually runs on a developer's machine, holds the file sandbox, and asks permission before the agent does something irreversible.

CVE-2026-82533 describes what happens when a different process on that same machine decides to ask instead. VulnCheck scores it 9.4 out of 10.

Three POST requests

The harness ships a web interface, and behind it a local control plane. That control plane has no authentication at all, and exposes more than 60 RPC methods.

The escape is three requests, in order:

  1. POST /api/session.create — creates a session with an arbitrary working directory. Anywhere on disk, chosen by the caller.
  2. POST /api/commands/execute with the command /permission danger-full-access — switches off the file sandbox and the approval prompts. Both, in one call.
  3. POST /api/session.prompt — hands the agent its instructions, which it now carries out with no filesystem boundary and nothing for a human to click through.

None of that is a memory corruption, a parser trick or a race condition. It is the product's own API, used exactly as documented, by a caller nobody asked to identify itself.

The fence was a request header

There was a check. It read the Host header on the incoming request and decided from that whether the caller was local.

The Host header is set by the client. That is the whole of it.

A browser will not lie about it, and that is why the check does something real. A malicious web page you happen to visit cannot reach the harness on localhost, because the browser will not forge a Host header on the page's behalf. That is a genuine class of attack, and the check stops it.

What it does not stop is anything that is not a browser. Any local process can put whatever it likes in that field. In the words of the developer who published the report, going by OracleNep, the fence "stops browser-based attacks" but "any non-browser local process passes it trivially".

The check read what the caller claimed about itself. It never read where the connection actually came from — the one property the caller cannot forge.

FreeIPA's ownership check said yes for the same reason: the control was inspecting an attribute the caller supplies.

The agent is the non-browser local process

This is what separates the finding from an ordinary unauthenticated localhost service, and it is why the CVE scores where it does.

The population of non-browser local processes on a developer's machine is not hypothetical. It includes build scripts, editor extensions, dependency install hooks — and it includes the coding agent itself, running whatever a repository, a README, a dependency or a pasted issue told it to run.

A sandboxed agent, the exact thing the harness exists to contain, sits squarely inside that population. So the failure is not a stranger reaching in from the network. It is the agent, inside its sandbox, sending three HTTP requests to the process that holds the sandbox, and being let out.

The boundary and the thing being bounded ended up on the same side of the check. And step two is not a bypass of the approval prompts — it is the supported command for turning them off, reachable by anyone who can send a request.

METR's write-up hit the same wall from the other direction, where the shortest path to a secret was to ask the agent for it rather than to break anything.

The disclosure, and the reply

OracleNep published on 14 August 2026, in GitHub discussion #853 — public, with the full three-step proof of concept in it.

The project replied. It said the web API "can drive agent actions", that "remote authentication is not available yet", that the documentation already tells people not to bind to 0.0.0.0, and that the report "has no significance". The finding was treated as user misconfiguration.

The bind-address argument is the one worth pulling apart, because it is the load-bearing claim. Binding to 127.0.0.1 rather than 0.0.0.0 keeps the control plane off the network, and that is worth doing. It does nothing at all about a process that is already on the machine — and a process already on the machine is the entire attack. The advice is correct and beside the point in the same sentence.

OX Research picked the report up and took it to VulnCheck, which assigned the CVE on 24 August 2026.

The fix arrived without saying anything

Affected: 0.1.1-rc.2 and earlier.

Fixed in 0.1.2-alpha.1, published to GitHub on 27 August 2026. The first npm release carrying the fix was 0.1.2-alpha.2, on 30 August 2026 — so anyone installing from npm had three further days with nothing available to them.

Both went out as routine changes. No security notice, no advisory, no mention of the CVE in the release notes.

The interval that matters is the one between those two dates: a working public exploit existed on 14 August, and the fix that closed it landed quietly on 27 August. Thirteen days in which the proof of concept was considerably easier to find than the patch, and nothing at all told the people running the affected version that either one existed.

What to do

  • Upgrade to 0.1.2-alpha.2 or later. The earlier fixed build was GitHub-only; if you install from npm, that is the first release that contains it.
  • Check your version by hand. This shipped without a security flag, so there was nothing for update tooling or vulnerability scanners to react to.
  • Treat the local control plane as a privileged surface. An unauthenticated API that can switch off its own approval prompts is not a debugging convenience.
  • Stop using 127.0.0.1 as an authorisation boundary. It is a network control, and every process on the box is already inside it.
  • Assume your agent can reach whatever your user account can reach, and scope the account accordingly rather than trusting the runtime's own fence.

What is not established

  • Whether it was exploited. Nothing has been reported.
  • How many installations are on affected builds. Alpha and release-candidate usage is not tracked publicly.
  • Whether the project intends real authentication, beyond the statement that remote authentication is not available yet.
  • Whether other methods among the 60-plus RPC endpoints reach the same place by shorter routes. Only three were needed, and nobody has published a review of the rest.