Like a prison where the inmates can already see and phone anyone — this bug just unlocked the cell door
DeepSeek Harness (dsh), DeepSeek's open-source AI agent runtime released in August 2026, exposes a local HTTP API on 127.0.0.1:3080 for controlling agent sessions. Versions through 0.1.1-rc.2 authenticate API requests by checking the Host header instead of the actual TCP peer address (CWE-807). A single curl call with Host: 127.0.0.1:3080 flips the session to dangerFullAccess mode and disables the approval prompt, letting the agent — or anyone who can reach the port — write anywhere on the filesystem and execute commands unconfined. All releases through 0.1.1-rc.2 are affected. Fixed in 0.1.2-alpha.1 (GitHub source, 2026-08-27), 0.1.2-alpha.2 (npm, 2026-08-30), and 0.1.2-rc.1 (stable, 2026-09-03).
The vendor CVSS of 9.6 CRITICAL materially overstates real-world risk. The vector uses AV:N (Network), but dsh hard-binds to 127.0.0.1 and rejects --host 0.0.0.0 — remote exploitation requires the operator to deliberately tunnel or proxy the port outward, a misconfiguration the tool actively prevents. More importantly, the dsh sandbox only ever restricted *file writes*; reads and outbound network were already unconfined even inside the sandbox. The escape adds write access and disables the approval UI, which matters for persistence and lateral-movement staging — but the headline-grabbing exfiltration scenario (reading SSH keys, cloud creds, .env files, and sending them out) was already possible *inside* the sandbox. The incremental risk is real but significantly narrower than a true unauthenticated network RCE.
5 steps from start to impact.
Attacker positions malicious instructions in agent context
curl requires zero exploit development. No special tooling needed; the payload is a natural-language instruction.- Attacker can influence the agent's context window (prompt injection, malicious file in workspace, social engineering of operator, or compromised upstream tool)
- Agent must interpret and act on the injected instruction — alignment guardrails may refuse overtly hostile prompts
- If the operator is actively watching the approval UI, they would see the curl call — but only if approval hasn't already been disabled in a prior turn
/api/session/config or dangerFullAccess.Host header spoofing bypasses API authentication
curl -H 'Host: 127.0.0.1:3080' http://127.0.0.1:3080/api/session/config -X PATCH -d '{"approval":"never","dangerFullAccess":true}'. The isTrustedApiRequest function checks only the Host header against a loopback allowlist and never compares it against the connection's actual peer address. No token, cookie, or credential is required. The full PoC is documented in the OX Security blog — it is a single command.- Ability to send HTTP to 127.0.0.1:3080 — the agent already has this from inside the sandbox (network is unconfined); a remote attacker needs a tunnel, SSH forward, or reverse proxy to the port
- Port binds to loopback only by default and the CLI rejects
--host 0.0.0.0, so accidental remote exposure is structurally prevented - Third-party desktop wrappers may bundle their own dsh copy, but these also bind to localhost
127.0.0.1:3080 from dsh child processes.Sandbox dropped, approval prompt disabled
dangerFullAccess: true and approval: never. The harness immediately drops OS-level sandbox confinement (bubblewrap on Linux, Seatbelt on macOS) and stops prompting the user for action confirmation. Critically, the OX Security researchers confirmed the config change is logged with source user rather than agent, leaving no forensic indicator that the agent modified its own policy. No user interaction is required for this step.- Step 2 succeeded
- None — the API applies the change immediately and unconditionally once the Host header check passes
/api/session/config GET response for unexpected dangerFullAccess state. No vendor audit log exists in affected versions.Unconfined execution as the host user
~/.ssh/authorized_keys entries, modify ~/.bashrc or ~/.zshrc, alter CI build scripts, plant cron jobs, or stage tools for lateral movement. Combined with the read and network access that was *already* available inside the sandbox, the agent now holds full interactive-user-equivalent access. On CI runners in headless mode, this includes build secrets, deploy tokens, and artifact-signing material.- Step 3 succeeded
- dsh is running as a user with access to valuable assets (developer credentials, CI secrets, source code)
- Impact limited to the privileges of the user running dsh — typically a non-root developer or CI service account
- EDR/XDR on the host may flag anomalous file writes or process trees from the Node.js dsh process
~/.ssh/, ~/.bashrc, CI config directories, or spawning unexpected binaries. File-integrity monitoring on sensitive dotfiles.(Alternative entry) Remote attacker via exposed tunnel
RemoteForward), ngrok, cloudflared, or a reverse proxy, an unauthenticated remote attacker can skip step 1 entirely. They send the same Host-header-spoofed PATCH to create a session, execute arbitrary commands, and exfiltrate all stored conversation transcripts — no prompt injection required. This is the scenario the vendor CVSS models, but it requires a deliberate misconfiguration that the tool actively resists.- Port 3080 is reachable from the attacker's network via tunnel, proxy, or port forward — a configuration dsh explicitly prevents by default
- dsh rejects
--host 0.0.0.0at the CLI level - Documentation and community guides (SSD Nodes, dsh-plugin.org) explicitly warn against exposing the port
- No Shodan/Censys/FOFA fingerprint tags exist for dsh, suggesting negligible public exposure
0.1.2-alpha.2 is the first npm-published release with one-time-token authentication on the local API. Run npm install -g @deepseek-ai/dsh@latest or update your package.json pin. Also audit third-party desktop wrappers that bundle their own dsh copy — at least one Windows wrapper shipped vulnerable 0.1.1-rc.2 until September 6. Per the noisgate remediation SLA for HIGH, complete within 180 days — but this is a one-command npm update with no reported breaking changes, so there is no reason to delay.~/.ssh, ~/.aws, ~/.config/gcloud, ~/.npmrc, or CI secret directories. The escaped agent gains write access to the container's filesystem only — no host credentials to steal, no meaningful persistence to establish. Per the noisgate mitigation SLA for HIGH, deploy within 30 days.~/.ssh/config, sshd_config) for RemoteForward or LocalForward directives targeting 3080. Search for ngrok, cloudflared, or similar tunnel agents. This does NOT mitigate the local sandbox-escape path but removes the most severe exploitation scenario. Per the noisgate mitigation SLA for HIGH, complete within 30 days — ideally within hours, as this is a configuration change.dangerFullAccess, approval.*never, or PATCH.*/api/session/config. This is detective, not preventive — it will not stop the escape but provides a forensic trail and early-warning signal. The OX Security researchers confirmed that the config change logs as source user so you must key on the content of the change, not the actor label.- WAF or network IDS/IPS — the primary attack vector is agent-to-localhost over the loopback interface; no inline network security tool inspects
127.0.0.1traffic. A WAF in front of a reverse proxy would only cover the remote misconfiguration scenario. - EDR signatures on
curl localhost—curlto localhost is ubiquitous in developer workflows, Node.js health checks, and CI scripts. Signature-based detection will generate overwhelming false positives and get tuned out within days. - Running dsh as a non-root user — the escape grants the agent the *same* privileges as the user running dsh. On a developer workstation, that user already owns SSH keys, cloud credentials, and code repositories. Non-root confinement does not protect these assets.
- Setting
--approval alwaysat launch — the vulnerability payload explicitly setsapproval: nevervia the API, overriding any CLI flag. The approval mechanism is itself the thing being bypassed.
The supporting signals.
| In-the-wild exploitation | None observed. No CISA KEV listing. No GreyNoise or Shadowserver scan tags. No attributed campaigns as of 2026-10-08. EPSS exploitation probability is 1.2%, confirming low observed threat actor interest. |
|---|---|
| Proof of concept | Fully public — trivial one-liner. The complete PoC (curl -H 'Host: 127.0.0.1:3080' … -d '{"dangerFullAccess":true}') is documented in the OX Security blog with before/after screenshots. No dedicated GitHub PoC repo (e.g., CVE-2026-82533) was found on pocindex.io or GitHub — the exploit is so trivial that a standalone repo is unnecessary. Researchers: Nir Zadok and Moshe Siman Tov Bustan (OX Security). |
| EPSS | 0.01204 (1.2%) — low exploitation probability in the next 30 days. Consistent with a localhost-only, niche developer tool. |
| KEV status | Not listed on CISA Known Exploited Vulnerabilities catalog as of 2026-10-08. |
| CVSS vector | Vendor: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H → 9.6. VulnCheck scored CVSS v4.0 at 9.4. The AV:N is inaccurate for default deployments — dsh binds to localhost and rejects --host 0.0.0.0. AV:L is more realistic for the primary (agent sandbox escape) path, which would drop the base to ~7.1. S:C (Changed scope) is appropriate: the vuln crosses the sandbox→host boundary. |
| Affected versions | All DeepSeek Harness releases through 0.1.1-rc.2 (released 2026-08-21). This includes the initial public release from August 13, 2026. GHSA: GHSA-8m2g-8cgm-3vcp. |
| Fixed versions | 0.1.2-alpha.1 (2026-08-27, GitHub source only) · 0.1.2-alpha.2 (2026-08-30, first npm publish) · 0.1.2-rc.1 (2026-09-03, current stable). Fix replaces Host-header trust with one-time-token auth + signed browser cookie on all API endpoints. Third-party desktop wrappers may still bundle vulnerable copies — one Windows wrapper shipped 0.1.1-rc.2 until 2026-09-06. |
| Exposure surface | dsh hard-binds to 127.0.0.1:3080 and programmatically rejects --host 0.0.0.0. No Shodan, Censys, or FOFA fingerprint tags exist for dsh instances. 216k GitHub stars are bookmarks, not installations. The tool is pre-alpha, developer-only, and has no enterprise distribution channel. Actual installed base in production environments is estimated to be very small. |
| Disclosure timeline | 2026-08-13: Community reports sandbox escape on DeepSeek discussion board. 2026-08-24: OX Security reports to VulnCheck (CNA). 2026-08-27: Fix in 0.1.2-alpha.1. 2026-08-30: npm publish of 0.1.2-alpha.2 + researcher verification. 2026-09-08: CVE published. |
| Researchers | Nir Zadok and Moshe Siman Tov Bustan, OX Security. Coordinated via VulnCheck as CNA. Community developers independently reported the same escape 11 days before the formal disclosure. |
Sources.
Why this verdict
- Localhost-only binding eliminates the network attack vector. The vendor CVSS uses
AV:N, but dsh binds to127.0.0.1and rejects--host 0.0.0.0at the CLI level. Remote exploitation requires the operator to deliberately tunnel or proxy port 3080 outward — a misconfiguration the tool structurally prevents. No Shodan/Censys/FOFA evidence of public-facing dsh instances exists. Recalculating withAV:Ldrops the realistic base score by approximately 2 points. - Sandbox already allowed reads and outbound network — incremental impact is narrower than the headline. The dsh sandbox only restricted file writes; an agent could already read
~/.ssh/id_rsa,~/.aws/credentials,.envfiles, and exfiltrate them over the network *without* this vulnerability. The escape adds write access (persistence, config modification) and disables the approval prompt (stealth). These are meaningful gains but the most dangerous exfiltration path was already open inside the sandbox. - Pre-alpha developer tool with negligible enterprise footprint. DeepSeek Harness was released August 2026 as a developer preview. It has no enterprise distribution channel, no LDAP/SSO integration, and no production deployment model. 216k GitHub stars are bookmarks, not installations. Actual enterprise deployment at scale is near-zero.
- No in-the-wild exploitation and low EPSS (1.2%). Not on KEV. No GreyNoise tags. No attributed campaigns. The exploit is trivially reproducible but the target population is small, local-only, and self-selecting (developers who opted into a pre-alpha AI agent tool).
- Role multiplier: (a) *Developer workstation* (>90% of installs): chain succeeds; blast radius is host-level. Attacker gains write access as the developer user, enabling persistence via dotfiles and access to dev credentials. Meaningful but bounded to one host and one user's credential set. (b) *CI/CD runner via
--headlessmode* (<10% of installs but a documented use case): chain succeeds; blast radius is potentially supply-chain-scale — an escaped agent can modify build artifacts, exfiltrate signing keys, or inject malicious code into CI pipelines. This is the high-value role that floors the verdict at HIGH. (c) *VPS with SSH tunnel*: remote exploitation is possible but requires deliberate misconfiguration; no evidence of meaningful exposure.
Why not higher?
CRITICAL would require either a network-reachable attack surface in default configuration or the affected component being canonically a high-value infrastructure role (identity provider, domain controller, hypervisor, network edge appliance). DeepSeek Harness is none of these — it is a pre-alpha developer tool that binds to localhost by design. The CI/CD mode creates real supply-chain risk but represents a minority deployment pattern, and the sandbox already permitted the most dangerous data-exfiltration operations (read all files, full outbound network) before the escape. The incremental severity gain from write access alone does not justify CRITICAL.
Why not lower?
MEDIUM would undercount the blast radius on CI/CD runners where sandbox escape can enable supply-chain compromise via build-artifact tampering or signing-key theft. The exploit is a single trivially reproducible curl command with no authentication, the PoC is fully public, and developer workstations hold high-value credentials (SSH keys, cloud tokens, API secrets, code-signing material). The write-access and approval-bypass gains enable persistence mechanisms and lateral-movement staging that the read-only sandbox could not support.
Crowdsourced verification payload.
Run on any host where DeepSeek Harness (dsh) may be installed. Invoke: bash check_cve_2026_82533.sh. No root required — needs node and npm in $PATH (they are present if dsh is installed). The script checks the installed dsh version against the fix threshold and warns if port 3080 is bound to a non-loopback address.
#!/usr/bin/env bash
# CVE-2026-82533 — DeepSeek Harness auth-bypass version checker
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
set -uo pipefail
FIXED="0.1.2-alpha.1"
VER=""
# --- Locate installed dsh version ---
if command -v dsh &>/dev/null; then
VER=$(dsh --version 2>/dev/null | grep -oE '[0-9]+\.[0-9]+\.[0-9]+[-a-zA-Z0-9.]*' | head -1)
fi
if [ -z "$VER" ] && command -v node &>/dev/null; then
for base in "$(npm root -g 2>/dev/null)" "$(npm root 2>/dev/null)"; do
[ -z "$base" ] && continue
pj="${base}/@deepseek-ai/dsh/package.json"
if [ -f "$pj" ]; then
VER=$(node -p "require('${pj}').version" 2>/dev/null)
[ -n "$VER" ] && break
fi
done
fi
if [ -z "$VER" ]; then
echo "UNKNOWN - DeepSeek Harness (dsh) not found on this host"
exit 2
fi
echo "[*] Detected dsh version: $VER"
# --- Semver comparison via node (guaranteed present if dsh is installed) ---
RESULT=$(node -e "
function cmp(a, b) {
var pa = a.split('-'), pb = b.split('-');
var ca = pa[0].split('.').map(Number), cb = pb[0].split('.').map(Number);
for (var i = 0; i < 3; i++) {
if (ca[i] !== cb[i]) return ca[i] - cb[i];
}
var ra = pa[1] || '~', rb = pb[1] || '~';
if (ra === '~' && rb === '~') return 0;
if (ra === '~') return 1; // no prerelease > prerelease
if (rb === '~') return -1;
return ra < rb ? -1 : ra > rb ? 1 : 0;
}
console.log(cmp('${VER}', '${FIXED}') >= 0 ? 'PATCHED' : 'VULNERABLE');
" 2>/dev/null || echo "UNKNOWN")
# --- Check for non-loopback exposure of port 3080 ---
if command -v ss &>/dev/null; then
EXPOSED=$(ss -tln 2>/dev/null | awk '/:3080 /{print}' | grep -v '127\.0\.0\.1' | grep -v '\[::1\]' || true)
if [ -n "$EXPOSED" ]; then
echo "[!] WARNING: port 3080 bound to non-loopback address — remotely exploitable!"
echo " $EXPOSED"
fi
elif command -v netstat &>/dev/null; then
EXPOSED=$(netstat -tln 2>/dev/null | awk '/:3080 /{print}' | grep -v '127\.0\.0\.1' | grep -v '::1' || true)
if [ -n "$EXPOSED" ]; then
echo "[!] WARNING: port 3080 bound to non-loopback address — remotely exploitable!"
echo " $EXPOSED"
fi
fi
echo "$RESULT - dsh $VER (fixed in >= $FIXED)"
case "$RESULT" in
PATCHED) exit 0 ;;
VULNERABLE) exit 1 ;;
*) exit 2 ;;
esac