Skip to main content
← All vulnerabilities
CVE-2026-55605GHSA-72F3-6W86-7RV3

@arikusi/deepseek-mcp-server Missing Authentication on Self-Hosted HTTP MCP Endpoint

Published
Last modified
published
Not listed in CISA KEV
Fix
Fixed in 1.8.0
None on Exploit-DB, Metasploit or GitHub
  • Exploitation: poc
  • Automatable: yes
  • Technical impact: partial

Summary

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.

Timeline

  1. CVE published
  2. CISA SSVC assessment

    Exploitation: poc · Automatable: yes · Technical impact: partial

  3. Record last updated

Affected versions

  • arikusi deepseek-mcp-server

    From 1.4.2 · fixed in 1.8.0

  • @arikusi/deepseek-mcp-servernpm

    From 1.4.2 · fixed in 1.8.0

References 3

GitHub · arikusi/deepseek-mcp-server