GHSA-72f3-6w86-7rv3

Описание

Summary

The self-hosted HTTP transport of @arikusi/deepseek-mcp-server exposes POST /mcp without any authentication: createMcpExpressApp is called without an authProvider and no middleware guards the route, so any network-reachable client can issue an unauthenticated initialize request and obtain a valid MCP session identifier. In reproduced testing against commit 5e1302171e99, an unauthenticated client was able to initialize a session, enumerate tools, and invoke the local deepseek_sessions tool with no credentials. The same unauthenticated session also exposes deepseek_chat, whose handler uses the server-side DEEPSEEK_API_KEY when self-hosted deployments configure one.

This issue applies to self-hosted HTTP mode, not the separately documented hosted BYOK endpoint in README.md, which expects an Authorization: Bearer ... header. Upstream self-hosted container assets enable HTTP mode by default (Dockerfile) and publish port 3000 (docker-compose.yml).

Affected Code

src/transport-http.ts:17 — createMcpExpressApp called without authProvider; no challenge is issued to incoming requests

src/transport-http.ts:31 — POST /mcp handler instantiates a full MCP session for any body that satisfies isInitializeRequest, with no preceding auth check

HTTP client → POST /mcp (no auth middleware) → transport-http.ts:41 (isInitializeRequest branch) → transport-http.ts:57–59 (serverFactory()+connect+handleRequest)

Dockerfile:12-13 — upstream container image defaults to self-hosted HTTP mode

docker-compose.yml:4-8 — upstream compose file publishes port 3000 and enables HTTP mode

Proof of Concept

Step 1 — send unauthenticated initialize: server returns HTTP 200 and a live mcp-session-id — proves no credentials are required to establish a session.

Step 2 — send unauthenticated tools/list on the obtained session: server returns the full tool surface (deepseek_chat, deepseek_sessions) — proves tool discovery is reachable without credentials.

Step 3 — send unauthenticated tools/call for the local deepseek_sessions tool on the obtained session: server executes the tool and returns its result with no credentials supplied.

Impact

In self-hosted HTTP deployments, any host with network access to port 3000 can establish an authenticated-equivalent MCP session and invoke built-in MCP tools without supplying credentials. This was verified end-to-end for session establishment, tool enumeration, and execution of the local deepseek_sessions tool.

deepseek_chat is exposed through the same unauthenticated MCP session, and its handler routes requests through the server-side DeepSeek client. That means a deployment using a valid server-side DEEPSEEK_API_KEY places billable DeepSeek operations behind an unauthenticated endpoint. However, this report's reproduced PoC used a dummy API key and did not directly validate successful upstream DeepSeek billing or quota consumption.

Remediation

Require authentication in self-hosted HTTP mode before MCP session creation. At minimum, pass an authProvider to createMcpExpressApp at transport-http.ts:17 or place equivalent authentication middleware / a reverse proxy in front of /mcp so unauthenticated clients never reach the initialize branch:

For deployments that only need local access, bind to 127.0.0.1 instead of 0.0.0.0 in both createMcpExpressApp and app.listen (transport-http.ts:17 and :107) as a defence-in-depth measure. Upstream docker-compose.yml currently publishes 3000:3000; changing that to 127.0.0.1:3000:3000 would reduce inadvertent exposure on multi-user or server hosts.