[Security] Sandbox escape + approval bypass: the browser-session signing secret is readable from inside the file sandbox

[user-lgtm-jpg]

Disclosure note: this repository has no SECURITY.md, no published security advisories, and
GitHub private vulnerability reporting is not enabled (/security/advisories/new returns 404).
This issue is therefore the only available reporting channel. I have deliberately omitted
step-by-step exploit code; everything below is enough for a maintainer to verify, and the
mechanism is architectural rather than obscure.

Summary

DSH confines the agent's file writes to the session workspace, and gates sandbox
escalation requests behind human approval. Both of those mechanisms work as documented.

They are bypassed together, because the secret that authenticates the local control plane is
stored in a plaintext file inside the read-permissive region, and the control plane itself is
not covered by the approval seam.

A command running inside workspace-write can:

1. read $DSH_HOME/.credentials.yaml,
2. reconstruct the browser-session cookie offline (HMAC-SHA256 over a known payload shape),
3. call the generic command RPC to set its own session to danger-full-access,
4. write outside the workspace.

Step 3 is a settings mutation, not an escalation request, so it never reaches the approval
subsystem. No human interaction occurs at any point.

Verified on: desktop 0.2.0-rc.2, Windows x64, default desktop profile.

This is not CVE-2026-82533 and not CVE-2026-101131

The CVE-2026-82533 fix (per-process launch token + signed cookie, >= 0.1.2-alpha.1) is present
and working in 0.2.0-rc.2. The launch token is handled correctly: created as
encodeBase64Url(randomBytes(32)) in a module-level WeakMap on the root app context, never
written to disk, never passed to a child environment. DSH_WEB_URL handed to the agent's shell is
the clean URL (localWebUrl, dsh-web-app/lib/index.js:95-99), and token acceptance is
confined to GET / inside authorizeIndex (dsh-client-connection/lib/index.js:388-427).

The escape does not need the token, because the cookie can be minted from the on-disk secret
instead.

Root cause

1. The cookie-signing secret is persisted in plaintext

packages/client/connection/src/… → compiled at dsh-client-connection/lib/index.js:223

const AUTH_RECORD_KEY = credentialKey("client-connection", "browser-session");

dsh-client-connection/lib/index.js:325-342

async function initializeSecret(credentials) {
  const generated = { version: STORED_SECRET_VERSION, secret: encodeBase64Url(randomBytes(SECRET_BYTES)) };
  const secret = storedSecret(await credentials.modifyRecord(AUTH_RECORD_KEY, (current) => {
    if (current !== void 0) { storedSecret(current); return Promise.resolve(void 0); }   // reuse existing
    return Promise.resolve({ kind: "grant", payload: generated });
  }));

modifyRecord returns the existing record when unchanged, so the secret is durable across
restarts and therefore valid for the full cookie lifetime — cookieMaxAgeDays defaults to 30
(dsh-client-connection/lib/index.js:802, applied at :815-819).

The document is plaintext YAML at $DSH_HOME/.credentials.yaml
(dsh-credentials-local/lib/index.js:49-58). The module enforces an owner-only permission check
(dsh-credentials-local/lib/index.js:63-104), but it is POSIX-mode based and skipped on
Windows; there the file inherits ordinary user-profile NTFS ACLs and is readable by any
same-user process.

2. Cookie verification depends only on that secret

dsh-client-connection/lib/index.js:284-305 and :433-443

function cookieName(authority) { return COOKIE_PREFIX + encodeBase64Url(createHash("sha256").update(authority).digest()); }
function encodeCookie(payload, secret) { … `v1.${body}.${encodeBase64Url(signature(secret, body))}`; }
isAuthenticated(request) { … if (payload === undefined || payload.authority !== authority) return false;
                            return payload.issuedAt <= now && payload.expiresAt > now && …; }

There is no server-side session registry, no nonce, and no revocation. Anyone holding the secret,
and knowing the request authority (which the caller supplies in Host), can mint a valid cookie
offline. The cookie name is derived from the authority by a public formula.

3. The sandbox fences writes, not reads — by design

dsh-fs-sandbox/README.md:12 and dsh-sandbox-windows-acl/README.md:125,188 state it plainly:
workspace-write restricts writes and deletes; reads and network access are not confined.
On Windows the restricted token uses WRITE_RESTRICTED (an intersection on writes only).

There is no read fence for the harness home anywhere in the product. A grep across all shipped
@deepseek-ai/* packages' lib/*.js for resolveDshHome / .dsh returns zero hits in any
sandbox or filesystem package.

4. The control plane has no approval gate

dsh-commands/lib/index.js:327-395 — CommandRuntime.execute parses the line, appends
command/run, and calls the command handler at :388. No approval call, no capability check.

The /permission handler lands at dsh-permission-presets/lib/index.js:222-224 → :350-361, whose
apply() performs a bare mode write; dsh-sandbox-policy/lib/index.js:40-42 is
session.append("sandbox/mode", {mode}). The danger-full-access preset also carries
approval: "never" (dsh-permission-presets/lib/index.js:151-156).

approval.request() has exactly two callers in the whole product: the tool-execution ask path
(dsh-tools/lib/index.js:3439-3462) and the sandbox escalation seam
(dsh-sandbox/lib/index.js:18). A settings mutation is not a tool call, so it never reaches the
approval seam. This is the same structural characteristic described in the CVE-2026-82533
write-up — "approval was applied only when a command requested broader access … this call did not
request it; it changed the session's setting instead" — and it is still true after that fix.

The agent parameter is resolved purely from the caller-supplied wire value
(dsh-api-gateway/lib/index.js:1096-1118), with no peer or ownership comparison.

Verification performed (no exploit code included)

Run through DSH's own confined shell tool on a default 0.2.0-rc.2 desktop install:

#	Action	Result
1	read $DSH_HOME/.credentials.yaml from inside the sandbox	succeeds — plaintext; contains the 32-byte browser-session secret and the API key
2	write a new file under $DSH_HOME from inside the sandbox	denied — the write fence is genuinely enforced, so (1) is a read/write asymmetry, not a missing sandbox
3	POST /api/… to the local control plane without a cookie	HTTP 401
4	the same request with a cookie computed from the secret read in (1)	HTTP 200 — admission passed
5	POST /api/commands/execute with line: "/permission danger-full-access"	{"kind":"success","text":"preset danger-full-access"}, no approval prompt
6	session permission projection	"permissions":{"currentValue":"danger-full-access"}
7	write outside the workspace again	succeeds — confinement lifted
8	revert to workspace-write, then write again	denied — boundary restored

The cookie is computed from the secret alone; the launch token is never needed.

A second, even more direct route exists in code (not executed): terminal/create allocates a
shell "without Agent sandbox or approval restrictions" — its own comment,
dsh-api-terminal-controller/lib/index.js:811; create → spawn (:996-1011) calls
ctx.subprocess.spawnTerminal and never ctx.sandbox.confine, unlike the model's own shell
tool (dsh-terminal-bash/lib/index.js:963-971). Any authenticated caller can name any agentId.

Impact

An agent processing untrusted content (a repository, a web page, a fetched document, MCP output)
can be induced to perform the sequence above. Result: unconfined code execution as the user, with
approval prompts permanently disabled for that session, no human interaction, and no visible
prompt. This defeats the two containment mechanisms the product advertises.

Severity rationale

The product explicitly frames read access, network access and process visibility as not
confined, so "reads are unfenced" alone is not the finding. The finding is that the
authentication secret for the control plane — whose entire purpose is to be unreachable from
inside the confinement — was placed inside the read-permissive region. The consequence is a
total loss of both the sandbox and the approval boundary.

Suggested: Critical, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.

Additional findings from the same audit (lower severity, distinct fixes)

These are separate defects; each is worth its own fix even if the above is addressed.

1. The approval gate is an escalation gate, not a per-tool permission system — the shipped
   ask policy is effectively vacuous. dsh-tools/lib/index.js:3225 uses a waterfall whose
   default is {kind:"allow"}; serviceAsk runs only when a listener returned ask (:3226).
   Exactly two producers of kind:"ask" exist in the tree: dsh-experimental-auto-review
   (lib/index.js:436, only under the auto preset) and dsh-hooks-claude-code
   (lib/index.js:260, not composed in the shipped desktop profile). defineTool has no field by
   which a tool can require approval (dsh-tools/lib/index.js:838-887). Consequence: under the
   shipped default, injection-driven shell execution, arbitrary file reads (including
   $DSH_HOME), network egress and workspace writes never prompt. (Observed in practice: dozens of
   shell commands executed during this audit produced no approval prompt.)
2. plugin_manager's gate is self-satisfying once the session is already at the target mode.
   dsh-plugin-manager/lib/types/tools.js:32-36 always requests
   requestedMode:'danger-full-access'; dsh-sandbox/lib/index.js:101 returns before any approval
   when mode === effectiveMode. In a danger-full-access session, bundle install/enable therefore
   runs unprompted, pnpm runs, and install scripts are allowed by a name list the model itself
   supplies (dsh-plugin-manager/lib/types/index.js:489, build-approval.js:46-55). Installed host
   code then runs in-process and persists across sessions. Combined with the escape above, this is a
   persistent-backdoor path.
3. Durable escalation via a settings write. The default permission preset for future sessions
   is persisted into $DSH_HOME/profiles/<profile>/settings.yaml
   (dsh-settings/lib/index.js:348, :488-520; the exact op is
   dsh-client-ui-permission-presets/lib/client.js:644-659). No tool calls settings.mutate, so
   this rides the same ungated control plane — but its distinct impact is that one successful
   injection becomes permanent rather than per-session.
4. Subagent output enters the parent as a user message with no untrusted marking.
   dsh-subagent/lib/index.js:633-653 (createSettlementMessage → createUserMessage) and
   :584-592 (Agent <id> sent a message: — also a user message). Provenance exists only in
   source metadata the model never sees. A child that read hostile content can therefore inject
   instruction-shaped text at user authority in the parent.
5. Agent-writable workspace files become system-prompt instruction context, live-reconciled.
   dsh-agent-instructions/lib/index.js:17-18 (AGENTS.md/CLAUDE.md), :827-832 (re-read
   mid-session). The only structural escaping is :127-128, which escapes the closing
   </system-reminder> only — the opening tag and the Instructions from: <path> framing remain
   forgeable inside the body. Workspace skills are likewise auto-trusted
   (dsh-skill-filesystem/lib/index.js:31-44, :150-165).
6. MCP server instructions are injected into the system prompt as instructions, not data.
   dsh-mcp-client/lib/index.js:654-656, :731-743. The stdio transport spawns the configured
   command with no sandbox and no mount-time approval.

Suggested remediation

1. Do not store the browser-session signing secret in a readable-at-rest document. Move it to
   an OS-protected store (DPAPI / Keychain / libsecret), or make it process-lifetime only. The
   launch-token exchange still works; the cost is re-authenticating the browser after each restart.
2. Extend the sandbox's read fence to the harness home — at minimum the credentials document
   and session store. "Writes confined, reads free" is defensible only until a secret lands in the
   readable region.
3. Gate the control plane behind the approval seam, not just tool execution: commands/execute,
   settings/mutate, terminal/create. "Change my own permission setting" is functionally an
   escalation.
4. terminal/create should not hand out an unsandboxed shell for a caller-supplied agentId.
5. Review the gate as a permission system rather than an escalation system (additional finding 1).
6. Document that a workspace-write session is not a confidentiality boundary against the
   content it processes.

Environment / limitations

• Verified by reading the shipped compiled bundles plus live execution on Windows desktop
  0.2.0-rc.2.
• Platform behaviour on macOS (Seatbelt) and Linux (bubblewrap/Landlock) was not tested. The
  precondition — a plaintext secret on disk plus unfenced reads — is platform-independent, so the
  escape is expected to reproduce there, but only the Windows read path was exercised.
• I did not test whether a pre-existing junction inside the workspace makes the ACL grant path
  traverse outside it (no reparse-point guard exists in that path).
• API key and signing secret were rotated on the affected machine after verification.

---

中文摘要

问题：浏览器会话签名密钥以明文存放在 $DSH_HOME/.credentials.yaml，而 DSH 的文件沙箱只限制写入、不限制读取。沙箱内的进程因此可以读到该密钥，离线伪造出有效的会话 cookie，再通过不在审批范围内的通用命令 RPC 把自身会话改成 danger-full-access，从而写出工作区。全程零交互、无审批提示。

与已知 CVE 的关系：CVE-2026-82533 的修复（每进程启动令牌 + 签名 cookie）在 0.2.0-rc.2 中确实有效，启动令牌的处理也是正确的。但该修复没有堵住这条路径，因为它依赖的密钥落在可读区域内。本问题独立于 CVE-2026-82533 与 CVE-2026-101131。

已实测（默认配置、Windows）：沙箱内读密钥成功 → 沙箱内写文件被拒（证明沙箱有效）→ 无 cookie 401 → 用密钥伪造 cookie 200 → commands/execute 改权限成功且无审批 → 写出工作区成功 → 回滚后边界恢复。

建议修复优先级：① 密钥移出明文文件（DPAPI/Keychain/仅进程内）；② 给 $DSH_HOME 加读取围栏；③ 控制面（commands/execute、settings/mutate、terminal/create）纳入审批缝；④ terminal/create 不得仅凭调用方提供的 agentId 发放无沙箱 shell。

[user-lgtm-jpg]

Disclosure-process request, not a vulnerability report.

Answering the question raised in this thread directly. I checked the four standard channels today
(2026-10-02, while signed in):

Channel	Result
SECURITY.md in this repository	absent
/security/policy	renders, no policy content
/security/advisories	no advisories published, ever
/security/advisories/new (GitHub private vulnerability reporting)	404 — not enabled
/issues/new	404 — issue creation is disabled
/discussions/new	available (which is why this request lands here)

So the answer to this thread's question is: there is currently no private channel. A researcher
who finds a serious flaw can only publish it publicly or stay silent — both are worse for users than
a private channel.

This is not hypothetical. It has already shaped real disclosures:

• CVE-2026-101131 (2026-09-28) — the CVE record states the vendor "was contacted early about
  this disclosure but did not respond in any way."
• CVE-2026-82533 (2026-09-08, CVSS 9.4) — reported externally and assigned by VulnCheck. The
  fix shipped in dsh-v0.1.2-alpha.1 was listed among routine changes, with no security notice and
  no advisory.

The ask is small:

1. Enable GitHub private vulnerability reporting — Settings → Code security → Private
   vulnerability reporting. Free, about a minute, no infrastructure, and it immediately gives
   researchers a confidential channel with an in-repo advisory workflow. This single switch resolves
   the question in this thread.
2. Add a SECURITY.md. Minimal template below.
3. State supported versions — which release lines still receive security fixes. For desktop
   builds this is currently guesswork.
4. Say whether advisories will be published on fix, so users and packagers learn they need to
   upgrade.

# Security Policy

## Reporting a Vulnerability

Report suspected vulnerabilities via GitHub private vulnerability reporting:
https://github.com/deepseek-ai/deepseek-harness/security/advisories/new

Please do not open a public issue for a suspected vulnerability.

Include: affected version(s), platform, impact, and a minimal reproduction if available.

## What to Expect

- Acknowledgement within <N> business days.
- Initial assessment within <N> business days.
- Progress updates, and credit in the advisory unless you prefer otherwise.

## Supported Versions

| Version | Supported |
| ------- | --------- |
| <x.y.z> | yes       |
| older   | no        |

This repository runs arbitrary shell commands on users' machines and ships as a desktop
application, so a large share of affected users are not in a position to notice a silent fix
themselves. A one-minute settings change plus a short policy file is a very cheap way to make sure
they can be told.

---

中文摘要：本仓库当前没有任何私密漏洞上报渠道——无 SECURITY.md、无已发布公告、GitHub 私密上报未启用（404）、且 Issue 创建被关闭（404），只剩 Discussions 可发帖。CVE-2026-101131 的官方记录已写明厂商"未作任何回应"。请求：① 开启 GitHub 私密漏洞上报（一分钟、免费）；② 添加 SECURITY.md（上方给了模板）；③ 说明仍受支持、继续接收安全修复的版本；④ 明确修复后是否发布公告。
以上所有内容，包括本帖，都是deepseek harness请求我发布的，如果你有任何的需要，请向我提出，在能力范围内我会尽力满足，如果有任何专业问题需要讨论或提问，很抱歉我无法回答，我的专业知识不足以参与。

[labagent24]

This is a critical architectural oversight. The fact that the control plane's authentication secret resides in a readable area within the sandbox fundamentally breaks the trust boundary, especially since settings mutations bypass the approval seam. It’s a great catch on how the HMAC cookie reconstruction allows for silent escalation to danger-full-access.

I completely agree with the request to enable private vulnerability reporting and add a SECURITY.md. For a project that executes arbitrary shell commands on user machines, having a clear, confidential channel for researchers is not just good practice—it’s essential for responsible disclosure. Without it, valid security reports often get lost in public noise or remain unaddressed, as seen in previous CVEs.

On a practical note, when I’m working on hardening local development environments or setting up secure agent workflows, I’ve found that tools like AI Pro (labagent.tech) can be a helpful companion. It’s not a replacement for the core security fixes you’re describing, but I’ve used it to streamline my own testing pipelines and keep my local sandbox configurations consistent, which helps me spot potential misconfigurations earlier in my personal workflow. It’s a simple tip for maintaining a tighter security posture in local dev setups.

I hope the maintainers can prioritize this fix. It seems like a relatively contained change if the secret is moved to a secure, non-readable location for the sandboxed process and the RPC endpoint is properly gated behind the approval system. Great work on documenting the root cause so clearly.