CVE-2026-82533: DeepSeek Harness Auth Bypass Vulnerability

CVE-2026-82533 Overview

CVE-2026-82533 is an authentication bypass vulnerability in DeepSeek Harness versions prior to 0.1.2-alpha.1. The local HTTP agent-control API trusts a client-supplied Host header set to a loopback value instead of validating the actual TCP connection origin. This allows a confined tool-executed process to reach the loopback API and escape its operating system sandbox, escalate to unconfined execution, and disable the approval prompt. When the port is externally reachable through a tunnel, SSH forward, or reverse proxy, remote attackers can create sessions, execute arbitrary commands, and exfiltrate stored conversation transcripts without credentials. The flaw is tracked under [CWE-807: Reliance on Untrusted Inputs in a Security Decision].

Critical Impact
Unauthenticated remote code execution and AI agent sandbox escape with full disclosure of stored conversation transcripts.

Affected Products

DeepSeek Harness versions before 0.1.2-alpha.1
Default configurations exposing the local agent-control HTTP API
Deployments where the loopback API port is proxied or tunneled externally

Discovery Timeline

2026-09-08 - CVE-2026-82533 published to NVD
2026-09-10 - Last updated in NVD database

Technical Details for CVE-2026-82533

Vulnerability Analysis

DeepSeek Harness exposes a local HTTP agent-control API used by the browser client to manage sessions, dispatch tool calls, and control approval prompts. Rather than verifying the TCP peer address of an incoming connection, the gateway grants trusted-host privileges whenever the request carries a Host header pointing at a loopback address. Any process able to send an HTTP request to the listening socket can therefore impersonate the trusted browser client. The gateway registered the /api endpoint with an { authority: 'trusted-host' } option that short-circuited authentication when the header claim looked local.

Root Cause

The root cause is a security decision based on attacker-controlled input. The Host header is user-supplied and forwarded verbatim by proxies, tunnels, and even confined child processes that share the loopback interface. Treating that string as evidence of a trusted origin conflates HTTP-layer metadata with transport-layer identity, matching the [CWE-807] pattern. WebSocket upgrade handling reinforced the pattern by returning a single 403 Forbidden response for all rejection paths, without distinguishing unauthenticated from browser-untrusted requests.

Attack Vector

A sandboxed tool process invoked by the agent can open a TCP connection to the loopback port, set Host: 127.0.0.1, and issue control-plane RPCs to spawn unconfined sessions and suppress approval prompts. Where the operator has exposed the port via SSH forward, reverse proxy, or a public tunnel, an unauthenticated network attacker can perform the same actions, execute arbitrary commands on the host, and read stored transcripts.

typescript

         '/api',
         endpoint => this.claimsEndpoint(endpoint),
         (endpoint, payload, signal) => this.dispatchRpc(endpoint, payload, signal),
-        { authority: 'trusted-host' },
       )
     })
     ctx.inject(['connection', 'webServer'], (webCtx) => {

Source: GitHub commit 3e24087. The patch removes the trusted-host authority shortcut so the /api endpoint enforces authentication regardless of the client-supplied Host header.

Detection Methods for CVE-2026-82533

Indicators of Compromise

HTTP requests to the DeepSeek Harness loopback API originating from non-browser processes or unexpected user contexts.
Inbound Host: localhost or Host: 127.0.0.1 requests received over a non-loopback network interface, tunnel, or reverse proxy.
Unexpected agent sessions created without a preceding interactive approval prompt, or approval prompts disabled outside operator action.
Outbound transfer of conversation transcript files from the DeepSeek Harness storage directory to unfamiliar destinations.

Detection Strategies

Monitor process lineage on hosts running DeepSeek Harness to identify tool-executed child processes making local HTTP connections to the agent-control port.
Alert on WebSocket upgrade attempts to the harness gateway from remote sources, especially those producing 401 or 403 responses after the patch.
Baseline the expected client identity for the /api endpoint and flag deviations in User-Agent, TLS fingerprint, or connection origin.

Monitoring Recommendations

Enable verbose access logging on the harness gateway and forward events to a centralized SIEM for correlation with sandbox and EDR telemetry.
Audit reverse proxy and tunnel configurations (ngrok, ssh -L, nginx) that expose loopback ports to external networks.
Track file access to conversation transcript storage and alert on reads from processes other than the harness itself.

How to Mitigate CVE-2026-82533

Immediate Actions Required

Upgrade DeepSeek Harness to version 0.1.2-alpha.1 or later, which removes the trusted-host authority shortcut on the /api endpoint.
Remove any tunnels, SSH port forwards, or reverse proxies that expose the local agent-control API to remote networks until the upgrade is applied.
Rotate any secrets, API keys, or credentials referenced in stored conversation transcripts that could have been exfiltrated.

Patch Information

The fix is delivered in GitHub release dsh-v0.1.2-alpha.1 via commit 3e24087. The patch enforces authentication on the browser Host API and updates rejectRemoteStreamUpgrade to differentiate 401 Unauthorized from 403 Forbidden responses. Additional analysis is available in the OX Security blog and the VulnCheck advisory.

Workarounds

Bind the harness gateway to a Unix domain socket where supported, or restrict its listener to an isolated network namespace inaccessible to sandboxed tools.
Apply host-based firewall rules that block all non-owner processes from connecting to the agent-control port.
Disable external exposure of the port and require operators to interact with the harness only through the local browser client on the same machine.

bash

# Restrict the DeepSeek Harness agent-control port to the owning user only
sudo iptables -A OUTPUT -o lo -p tcp --dport 3000 \
  -m owner ! --uid-owner deepseek -j REJECT

# Verify no external tunnels or proxies are exposing the loopback port
ss -tlnp | grep -E '3000|deepseek'