CyberRota Analysis
AI-GeneratedThe DeepSeek MCP Server, specifically versions 1.4.2 to 1.7.9, is vulnerable due to the exposure of the `POST /mcp` endpoint without authentication, allowing any network-accessible client to initialize a session and access sensitive functionalities, including tool enumeration and invocation of the `deepseek_sessions` and `deepseek_chat` tools. This vulnerability poses a risk of unauthorized access to sensitive operations and data, particularly for self-hosted deployments that enable HTTP mode by default. Organizations utilizing affected versions of the DeepSeek MCP Server should prioritize upgrading to version 1.8.0 or later to mitigate this risk.
Public Exploit Signal
A public exploit, PoC, GitHub repository or Metasploit reference was detected for this CVE.
Note: these links are listed for security research and verification purposes only.
Original NVD Description
DeepSeek MCP Server is an MCP server for DeepSeek V4. Starting in version 1.4.2 and prior to version 1.8.0, 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`). Version 1.8.0 contains a patch for this issue.