[Security] Cross-session approval hijack in the dsh web gateway allows unauthenticated local code execution

[qinaigonghe]

Security disclosure — verified end-to-end against the default configuration on rc.5@47f943859b.

This repo has no SECURITY.md, private vulnerability reporting is not enabled, and Issues are disabled, so per the README this report is posted as a discussion.

---

SUMMARY
The dsh Web gateway broadcasts every session's pending tool-approval and user-question
prompts over a global, unauthenticated WebSocket stream (/api/events.mux) and settles
them via /api/respond keyed only by rpcId, with no binding between the answerer and
the session owner. Any local process or page — or any LAN peer when the server is
exposed — can silently approve or reject another session's human-in-the-loop decisions.
Verified on the default configuration: an attacker answered a victim session's
danger-full-access sandbox escalation and the command executed on the host without the
victim human ever clicking.

VULNERABILITY DETAILS
The gateway (default http://127.0.0.1:3080) holds one process-wide pending-approval
table (pendingApprovals) and one global set of mux subscriber queues (muxQueues).

1. Global broadcast: every approval/request is pushed as an approval/requested
   server-request to ALL connected mux queues, and a new mux subscriber receives a
   replay of every session's still-pending approvals/questions.

   • packages/host/apiproxy/src/api-proxy.ts:3432-3447 (mux baseline + replay)
   • packages/host/apiproxy/src/api-proxy.ts:1467-1484 (approval push loop)
     The stream is WebSocket-only (/api/events.mux; plain GET -> 426) and carries no
     parameters, token, or session-owner binding.
   • packages/client/connection/src/index.ts:146-152

2. Unbound answering: /api/respond routes by the echoed rpcId through
   pendingApprovals and validates only that the payload's approvalId/sessionId
   match the pending entry. The answer payload schema is exactly three fields
   (sessionId, approvalId, outcome), and the client-response envelope has no
   identity field. respond is not in PRIVILEGED_METHODS.

   • packages/host/apiproxy/src/api-proxy.ts:3696-3720
   • packages/host/apiproxy/src/api/approvals.schema.ts:26-33
   • packages/host/apiproxy/src/api/rpc.schema.ts (clientResponseSchema)
   • packages/host/apiproxy/src/fetch/handler.ts:277-282
   • packages/client/connection/src/index.ts:89-126 (privileged-method list)

   The same rpcId-only routing also lets an attacker answer another session's
   ask_user_question prompts (api-proxy.ts:3717-3745).

REPRODUCTION (verified end-to-end on rc.5@47f943859b, real provider, default
workspace-write + approval: ask)

1. Victim session asks bash to write a file outside the workspace; the sandbox denies
   it and the model retries the same command with
   sandbox_permissions: "danger-full-access" + justification (its sanctioned
   escalation path). An approval is suspended for the victim session.
2. Attacker (plain WebSocket + curl, no session/UI) receives the victim's frame:
   {"rpcId":"304d7b36-c552-42c0-b5b5-445d1e16e1cd","method":"approval/requested",
   "payload":{"type":"approval/requested",
   "sessionId":"session-f0ec9c08-1248-45c8-9252-be8dafaae877",
   "approvalId":"53469106-6520-4a13-9860-605fe3093793",
   "toolName":"bash","callId":"call_00_ubOxPeXMj9gwFQiQ10J82254",...}}
3. Attacker answers:
   curl -s -X POST http://127.0.0.1:3080/api/respond -H 'content-type: application/json'
   -d '{"type":"client-response","rpcId":"304d7b36-...",
   "result":{"ok":true,"value":{"sessionId":"session-f0ec9c08-...",
   "approvalId":"53469106-...","outcome":"allowed-once"}}}'
   -> {"accepted":true}
4. Observed: mux broadcasts approval/resolved; victim audit shows
   approval/asked (seq 2635) -> approval/decided (seq 2636, allowed-once) with no
   human interaction; the bash call executes under danger-full-access
   (tool/result: PROBE, exit 0) and writes a workspace-external file
   (/Users/lihao/Documents/dsh-outside-workspace-probe.txt, cleaned up after test).
   A one-line variant with "outcome":"rejected" silently vetoes the victim's legitimate
   approvals; the first responder to settle an rpcId wins.

IMPACT
Unauthenticated local process (other user, malware, compromised same-origin page, or
LAN peer when the server is exposed with --host 0.0.0.0 and a matching Host) can grant
itself danger-full-access command execution on the dsh host through another user's
session, or veto that user's approvals, without consent and leaving only a forged audit
record. The same primitive hijacks ask_user_question prompts. This breaks the product's
stated human-in-the-loop approval contract across sessions.

AFFECTED VERSIONS

• Verified: 0.1.0-rc.5 (commit 47f9438).
• Assumed: any version carrying the global mux broadcast and rpcId-only respond routing
  (rc.6 not available for verification).
• No SECURITY.md / published disclosure policy exists in the repo.

PATCHED VERSIONS

• None at the time of writing.

SEVERITY

• CVSS 3.1: AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H = 8.8 (High); AV:N (9.8) when exposed
  beyond loopback.
• CWE-862 (Missing Authorization). The trust fence is explicitly documented as "not an
  auth layer".

RELATIONSHIP TO PRIOR REPORTS

• BUG: sandbox 内模型可通过 Web approval 回环通道自批准 `danger-full-access` #250 (agent self-answering its own approvals): cross-session path does not depend on
  the model and survives that fix.
• Fz0x00 G-5 (passive mux eavesdropping): shared root; new capability here is ACTIVE
  cross-session answering of approvals and questions.
• P16 (session.search lacks per-cwd authorization): related gap, different endpoint.

SUGGESTED FIX

1. Bind the answerer to the session owner (per-session downlink token issued at
   create/resume; /api/respond must prove it).
2. Scope approval/question frames to the owning session's own subscriptions only.
3. One-time nonce in approval/requested, echoed in respond.
4. Record the answering channel/identity in the audit trail.

REFERENCES

• packages/host/apiproxy/src/api-proxy.ts:3432-3447, 1467-1484, 3696-3720, 3717-3745
• packages/host/apiproxy/src/api/approvals.schema.ts:26-33
• packages/host/apiproxy/src/api/rpc.schema.ts (clientResponseSchema)
• packages/host/apiproxy/src/fetch/handler.ts:277-282
• packages/client/connection/src/index.ts:89-152
• packages/interaction/user-approval/src/index.ts:261-274

CREDITS

• Reporter: lihao (https://github.com/qinaigonghe)
• Discovery & verification: 2026-08-14, end-to-end on rc.5@47f943859b (macOS, real
  DeepSeek provider, default workspace-write + approval: ask).

TIMELINE

• 2026-08-14: Discovered, verified, drafted.
• [submission date]: Reported publicly via GitHub Discussion (repo has no private channel).
• [90-day window]: Disclosure default.