CVE-2026-55605

MediumCVSS 5.3

Published: 09/07/2026(UTC)Updated: 10/07/2026(UTC)Translated: 14/07/2026(UTC)NVD NIST

Exploitation Probability (EPSS)

Low risk

0.43%

35th percentile - higher than 35% of all known CVEs

Summary

A vulnerability in the DeepSeek MCP Server (versions 1.4.2 through 1.7.x) allows unauthenticated clients to access the HTTP POST /mcp endpoint. The lack of authentication enables session initialization, tool enumeration, and invocation of deepseek_sessions and deepseek_chat tools, potentially exposing the DeepSeek API key.

Risk Assessment

The organization faces unauthorized access to the MCP interface, which could lead to sensitive data leakage (e.g., API key) and uncontrolled resource usage. An attacker on the network can hijack sessions and perform operations without administrator knowledge.

Recommendation

Immediately update @arikusi/deepseek-mcp-server to version 1.8.0 or later. If an update is not possible, implement authentication at the proxy level (e.g., API Gateway) or restrict access to port 3000 to trusted networks only.

Other vulnerabilities in DeepSeek MCP Server

CVE-2026-55604High
A vulnerability in DeepSeek MCP Server allows an attacker to hijack user sessions by enumerating session IDs and reusing them in chat requests. The issue affects versions 1.4.2 through 1.7.0, where the global session store does not validate session ID authenticity.

Original NVD description (English source)

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.