CVE-2026-55605: Unauthenticated MCP Endpoint in DeepSeek MCP Server 1.4.2–1.7.x

Technical summary

The vulnerability stems from `createMcpExpressApp` being instantiated without an `authProvider` parameter and the `/mcp` POST endpoint lacking authentication middleware. An unauthenticated client can send an MCP protocol `initialize` request, receive a valid session identifier, and then use that session to invoke MCP tools. Testing against the affected codebase confirmed the ability to call `deepseek_sessions` (exposing session metadata) and `deepseek_chat` (which invokes the DeepSeek API using the server's configured `DEEPSEEK_API_KEY`). The vulnerability is scoped to self-hosted HTTP deployments; the separately documented BYOK hosted endpoint enforces `Authorization: Bearer ...` header validation. Official container images compound exposure by defaulting to HTTP mode and publishing port 3000 without authentication overlays.

Business impact

For organizations running self-hosted DeepSeek MCP Server instances without network segmentation, this vulnerability allows unauthenticated API abuse. An attacker can exhaust DeepSeek API quotas and incur costs using stolen credentials, enumerate or manipulate session state, and potentially exfiltrate session metadata. The risk is most acute for deployments exposed to untrusted networks or the public internet. Internal corporate networks with strict egress filtering face lower practical risk, though lateral movement attacks remain possible.

Affected systems

Self-hosted deployments of `@arikusi/deepseek-mcp-server` versions 1.4.2 through 1.7.x running in HTTP mode. The default Docker image configuration (`Dockerfile` and `docker-compose.yml` as published upstream) is vulnerable out-of-the-box. The hosted BYOK endpoint documented in the repository README is not affected. Version 1.8.0 and later include a patch.

Exploitability

Exploitability is high for externally reachable instances and moderate for internal-only deployments. An attacker needs only network connectivity and basic familiarity with the MCP protocol; no authentication or privilege escalation is required. The attack surface is the `/mcp` endpoint listening on the default port (3000). No user interaction or advanced techniques are needed—straightforward HTTP POST requests suffice. However, practical impact depends on deployment topology and whether the server has valid API credentials configured.

Remediation

Upgrade to version 1.8.0 or later, which implements proper authentication on the `/mcp` endpoint. If immediate patching is not possible, restrict network access to the MCP server port (3000) to trusted clients only using firewall rules, network segmentation, or reverse-proxy authentication. For container deployments, do not expose port 3000 to untrusted networks and consider running the service behind an authenticating reverse proxy (e.g., nginx with auth modules). Rotate any `DEEPSEEK_API_KEY` that may have been exposed during the vulnerability window.

Patch guidance

Update `@arikusi/deepseek-mcp-server` to version 1.8.0 or later. Verify the patch by confirming that the `/mcp` endpoint now requires valid authentication before accepting MCP `initialize` requests. Test in a staging environment to ensure compatibility with existing deployments before rolling out to production. Check the vendor's advisory and release notes for any additional configuration changes or migration guidance.

Detection guidance

Monitor HTTP access logs for POST requests to `/mcp` endpoints originating from unexpected sources or lacking proper authentication headers. Alert on repeated `initialize` requests to the MCP endpoint within short time windows. If available, enable detailed application logging in the MCP server to capture session initialization events and tool invocations. Network-level detection should flag traffic to port 3000 from external or untrusted network segments where the service should not be accessible.

Why prioritize this

Although the CVSS score is moderate (5.3), the practical risk is elevated due to the complete absence of authentication barriers. Any self-hosted instance exposed beyond a trusted network perimeter should be treated as high priority. Instances with valid API credentials configured carry additional risk of financial impact through quota exhaustion. Organizations should prioritize based on deployment topology: externally exposed instances are critical; internal-only instances without API credentials are lower priority but still warrant timely patching.

Risk score, explained

The CVSS 3.1 score of 5.3 reflects a network-accessible vulnerability with low complexity and no authentication requirement (high exploitability), but limited scope and impact. The score assumes no confidentiality breach (tools do not directly leak secrets) and no direct integrity damage, hence a medium severity rating. However, the actual business risk may be higher for organizations with exposed deployments and configured API credentials, where quota exhaustion and financial impact are possible.

Frequently asked questions