---
id: "CVE-2026-116368"
kind: "vulnerability"
aliases: ["CVE-2026-116368"]
title: "DeepSeek Harness: browser auth flaw allows improper authorization remotely"
severity: "high"
cvss: 7.5
epss: null
exploited: false
status: "open"
category: "ai-tooling"
products: [{"name": "DeepSeek Harness", "fixed": [], "affected": ">= 0.2.0-rc.0, <= 0.2.0-rc.2", "ecosystem": "other"}]
ecosystems: []
tags: ["ai-agents", "ai-tooling", "deepseek-harness", "prompt-injection", "sandbox-escape", "self-hosted"]
not_affected_if: ["loopback-only", "no-untrusted-agent-input"]
published_at: "2026-10-26T16:17:18+00:00"
first_seen_at: "2026-10-26T16:31:01+00:00"
updated_at: "2026-10-26T16:33:27+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-116368", "first_seen_at": "2026-10-26T16:31:01+00:00"}, {"source": "analyst", "url": null, "first_seen_at": "2026-10-26T16:33:27+00:00"}]
---

# DeepSeek Harness: browser auth flaw allows improper authorization remotely

DeepSeek Harness 0.2.0-rc.0 to 0.2.0-rc.2 has an improper-authorization flaw in its browser-session auth (browser-auth.ts). VulDB reports it is remotely exploitable without authentication, with no public exploit and no vendor response. A public maintainer-repo discussion (#8678) describes a likely related path. The cookie-signing secret sits in plaintext in $DSH_HOME/.credentials.yaml, where a sandboxed agent command can read it. The agent can then forge a valid session cookie, call the local control-plane API, switch itself to danger-full-access and skip approval prompts. That discussion does not cite this CVE.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- other:DeepSeek Harness affected >= 0.2.0-rc.0, <= 0.2.0-rc.2 fixed ?

## How to check

- Run the dsh/DeepSeek Harness version command and compare it with 0.2.0-rc.0, rc.1 and rc.2 (the versions VulDB lists as affected).
- Check whether $DSH_HOME/.credentials.yaml exists and holds a browser-session secret; if so, a sandboxed command can read it.
- Check whether dsh web is started with --host <non-loopback> or --trusted-host. The default bind is 127.0.0.1.

## Fix

unknown: no fixed version or vendor advisory exists. VulDB found no countermeasure. Discussions mention master at 0.2.1-alpha.3, but nothing confirms a fix there. Settle it by checking the repo release notes or a commit touching browser-auth.ts. Until then, avoid running untrusted content through the agent, don't expose dsh web beyond loopback, and rotate the API key stored in .credentials.yaml if exposure is suspected.

## Timeline

- 2026-10-26T16:31:01+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-116368
- 2026-10-26T16:33:27+00:00 analyst — No vendor advisory or fix exists (repo has no SECURITY.md/advisories; VulDB says vendor never responded). VulDB lists rc.0-rc.2 affected. Public GitHub Discussion #8678 (Oct 2) describes a closely matching issue in the same browser-session auth, but it does not cite this CVE, so the link is likely but unconfirmed. Nothing verified.

## Documents

- [advisory] VulDB VDB-426332 CVE-2026-116368 https://vuldb.com/vuln/426332
- [mentions] Sandbox escape + approval bypass: browser-session signing secret readable from file sandbox (Discussion #8678) https://github.com/deepseek-ai/deepseek-harness/discussions/8678

## From the sources

A vulnerability was determined in DeepSeek Harness up to 0.2.0-rc.2. This issue affects some unknown processing of the file packages/client/connection/src/browser-auth.ts of the component Browser Auth. This manipulation causes improper authorization. The attack can be initiated remotely. The vendor was contacted early about this disclosure but did not respond in any way.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_