Security: dsh web has no authentication and is reachable by every local user on shared multi-user hosts

[zyg992018]

Summary

dsh web (the browser UI / API server of DeepSeek Harness) listens on a loopback TCP port (127.0.0.1:3080 with default settings) and serves its full API without any authentication. On shared, multi-user Linux hosts, loopback is host-wide rather than per-user: every local account can reach the port (e.g., via their own ssh -L 3080:127.0.0.1:3080 tunnel, or by running a client directly on the host). A local user can then:

• read all sessions / conversation content of the instance (including tool outputs);
• register arbitrary paths — including other users' world-readable data — as workspaces and read them through the agent;
• create sessions and drive agents that execute arbitrary commands with the privileges of the account that runs dsh web (shell + file access).

On a host shared by many users (common in labs and teams), the default loopback binding provides no isolation at all. We consider this a privilege-escalation and cross-user data-exposure issue for shared-host deployments.

Environment

• Package: @deepseek-ai/dsh 0.1.0-rc.6 / 0.1.0-rc.7 (dsh --profile web)
• OS: shared multi-user Linux server
• Launched with defaults (no --host / --port / --trusted-host overrides)

What we observed

1. dsh web binds to 127.0.0.1:3080 (loopback only), started from an ordinary, unprivileged account.
2. The web UI has no login / password / token / session credential. The only protection on /api is the "browser-trust" fence, whose own source comment says it "is not an auth layer" and only defends against DNS rebinding and cross-site requests. Non-browser clients pass the same fence via loopback, so the API is trivially scriptable with curl from any local account.
3. In our deployment, a workspace pointing at another local user's world-readable data directory appeared in the instance, and an agent session was opened inside it — we did not create it. This is exactly what any other local user can do from the loopback GUI/API.
4. An agent session has full tool access (shell, file operations) as the OS user running dsh web, so a caller effectively gains that account's command execution.

Impact

• Cross-user data exposure: any local user can add any world-readable path as a workspace and read the contents through the agent.
• Privilege escalation: any local user can drive an agent to run arbitrary commands as the dsh web owner (a full shell as that user).
• Confidentiality: all session transcripts of the instance are readable.

Suggested fixes (any of these would help substantially)

1. Add real authentication to the web UI/API: e.g., a --token / --password option checked on every request, or a one-time pairing token printed at startup.
2. Default to a per-user Unix domain socket (e.g., under $XDG_RUNTIME_DIR, which is 0700 per user) instead of a TCP loopback port; expose TCP only when explicitly requested via --host.
3. Warn at startup when binding a TCP port on a multi-user host, and document the threat model: loopback on a shared host is shared.
4. Restrict workspace registration to paths the operator explicitly grants (the current UI accepts arbitrary paths).

Note

This report intentionally contains no personal information, account names, or host identifiers.

[zyg992018]

补充一个疑似真实案例：#2756 报告了 API key 在未使用的情况下于夜间被消耗。这与本讨论描述的无认证 Web GUI 场景一致：在共享/多用户主机上，任何本机账号可无需登录访问 dsh web，agent 以运行账号的权限执行命令并可读取其凭据。若该案例与本问题同源，说明此问题已造成实际损失，建议优先修复，并考虑发布安全公告。