CVE-2026-55605 in deepseek-mcp-server
Summary
by MITRE • 07/10/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/10/2026
The vulnerability exists within the DeepSeek MCP Server implementation where unauthenticated access is permitted to the POST /mcp endpoint through the createMcpExpressApp function call lacking proper authentication mechanisms. This flaw affects versions 1.4.2 through 1.7.9 of the @arikusi/deepseek-mcp-server package, creating a critical security risk in self-hosted deployments that utilize HTTP transport mode. The absence of an authProvider parameter during application initialization allows any external client with network access to establish authenticated sessions without proper credential validation, effectively bypassing the intended security controls.
The technical implementation flaw stems from the server's configuration where no middleware guards are implemented to protect the /mcp endpoint route, resulting in a complete lack of authentication checks for incoming requests. This vulnerability manifests through the ability to send unauthenticated initialize requests that successfully generate valid MCP session identifiers, which then grant full access to all exposed tools within the server environment. The security weakness directly maps to CWE-306 Missing Authentication for Critical Function, as essential server functionality operates without proper credential verification.
Operational impact of this vulnerability extends beyond simple unauthorized access to include potential data exfiltration and command execution capabilities. An attacker can enumerate available tools through the session, invoke the local deepseek_sessions tool without authentication, and leverage the exposed deepseek_chat functionality that utilizes the server-side DEEPSEEK_API_KEY for processing requests. This creates a scenario where sensitive API keys could be compromised and used for unauthorized operations against external services. The vulnerability affects self-hosted HTTP mode deployments specifically, not the documented hosted BYOK endpoint which correctly expects Authorization headers.
The root cause is embedded in the default configuration of the containerized deployment where HTTP mode is enabled by default through Dockerfile settings and port 3000 is published via docker-compose.yml, making the vulnerable endpoint immediately accessible to any network client. This design flaw follows ATT&CK technique T1219 Remote Access Software for Persistence, as it creates an unauthorized access point that could be exploited for ongoing system compromise. The vulnerability exists because the server implementation does not enforce proper authentication controls at the application layer, allowing unauthenticated requests to progress through the initialization process and establish valid sessions.
Mitigation strategies require immediate deployment of version 1.8.0 which includes the necessary patch addressing this authentication gap. Organizations should also implement network-level controls such as firewall rules to restrict access to port 3000, particularly in production environments where such exposure is unnecessary. Additional defensive measures include deploying reverse proxies with proper authentication mechanisms, implementing rate limiting for initialization requests, and ensuring that sensitive API keys are not exposed through server-side tool handlers. The fix addresses the core issue by enforcing proper authentication checks within the createMcpExpressApp function, preventing unauthorized session establishment while maintaining legitimate functionality for authenticated users.