CVE-2026-55604: @arikusi/deepseek-mcp-server has an Authorization Bypass Through User-Controlled Key

The server keeps conversations in a process-wide SessionStore (src/session.ts). It accepts any session_id the caller supplies and ties it to no user or transport session. deepseek_sessions with action: "list" (src/tools/deepseek-sessions.ts) prints every active id. deepseek_chat (src/tools/deepseek-chat.ts) then loads the stored messages for the supplied id, puts them in front of the attacker's message, sends them to the DeepSeek API, and appends the new turn to the victim's session.

In HTTP mode with several clients, a connected client therefore reads the other users' prompts and model answers, which may hold code, secrets or business data pasted into chats. It can also inject messages that the victim's next turn will carry, and the sessions tool can delete or clear other clients' sessions. The advisory rates this C:H, I:L, A:L.

The attacker needs to be a client of the same HTTP server, with no further authentication. The report was tested against 1.6.0 with a mock DeepSeek client. Single-user STDIO setups are not exposed, because each client runs its own process.

npm package @arikusi/deepseek-mcp-server from 1.4.2 up to but not including 1.7.0, when run with the HTTP transport (TRANSPORT=http) and shared by more than one client. Those versions are deprecated on npm. STDIO deployments are not affected.

Check:

npm ls @arikusi/deepseek-mcp-server
npm ls -g @arikusi/deepseek-mcp-server
env | grep TRANSPORT

Upgrade to 1.7.0:

npm install @arikusi/[email protected]

Each HTTP session now has its own SessionStore, so history, listings and deletion stay inside the session that created them. This is a breaking change for HTTP users who shared sessions across clients, and the activeSessions usage stat now returns 0 in HTTP mode. Library users must replace SessionStore.getInstance() with new SessionStore() and pass it to registerChatTool, registerSessionsTool and registerAllTools.

Workaround from the advisory: run in STDIO transport by unsetting TRANSPORT=http, or stop the HTTP server. Treat conversations held in a shared server's memory as exposed, and restart the process after upgrading to drop old sessions.

The server gives no audit log for this in the sources. Check your HTTP front end or MCP gateway logs for deepseek_sessions calls with action: "list" from clients that have no reason to list sessions, and for deepseek_chat calls where one client uses a session_id first created by another client.

Also review who can reach the HTTP port. If it is open to several users or agents, assume prompts stored in memory could have been read since 1.4.2.

Cross-Session Data Exposure via Caller-Controlled session_id

Project / Repository: arikusi/deepseek-mcp-server Affected version / commit tested: 1.6.0 / 04f28be2c6e99d3d4e443a6ae37cc35f0a71554a Vulnerability type: Authorization bypass / cross-session data exposure Authentication required: No

Summary

The process-global SessionStore accepts caller-supplied session_id values without binding them to any authenticated principal or transport session. An attacker can enumerate active session IDs via deepseek_sessions, then reuse a victim-controlled session_id in deepseek_chat to retrieve and continue the victim's conversation context.

Affected Code

• src/session.ts:42 - caller-controlled session IDs are looked up directly from the global in-memory map.
• src/session.ts:67 - a new session is stored under the caller-controlled ID without ownership binding.
• src/session.ts:109 - getMessages() retrieves messages for any supplied session ID.
• src/tools/deepseek-chat.ts:195 - deepseek_chat creates or reuses the supplied session_id.
• src/tools/deepseek-chat.ts:197 - previous messages are loaded from the supplied session_id.
• src/tools/deepseek-chat.ts:198 - previous messages are prepended into the attacker-controlled request.
• src/tools/deepseek-chat.ts:243 - attacker-provided user messages are appended into the reused session.
• src/tools/deepseek-chat.ts:245 - assistant responses are appended back into the reused session.
• src/tools/deepseek-sessions.ts:37 - deepseek_sessions list enumerates all active sessions.
• src/tools/deepseek-sessions.ts:53 - each enumerated session ID is rendered back to the caller.

PoC Overview

1. Create a victim conversation with session_id = "victim-session".
2. Call deepseek_sessions with action = "list" and observe that victim-session is disclosed.
3. Call deepseek_chat again with session_id = "victim-session" from a separate attacker flow.
4. The upstream request now includes the victim's prior messages before the attacker's message.

Validation Environment

Local runtime verification on Windows host with Node.js v24.11.1, using the repository code at the tested commit and a local mock DeepSeek client to capture the effective message list passed upstream.

Impact

Any reachable caller can enumerate active session IDs and read prior conversation history stored in memory for other callers within the same server process. The same flaw also allows attacker-controlled continuation of another user's session state.

Remediation

• Bind stored sessions to an authenticated transport session or other server-generated opaque identifier.
• Do not allow arbitrary user-supplied session_id values to select existing server-side state.
• Remove or restrict deepseek_sessions list so it does not disclose unrelated session IDs.
• Reject reuse of a session unless the caller proves ownership of that session.

Attached Evidence

01_deepseek-mcp-server_cross_session_data_exposure.txt

---

Patches (maintainer)

Fixed in 1.7.0. The HTTP transport's SessionStore is no longer a process-wide singleton: each MCP HTTP session gets its own store, injected into the deepseek_chat and deepseek_sessions tool handlers, so a session_id from one HTTP session cannot read, enumerate, or clear another session's state. STDIO transport was never affected (one process per client). Integration tests in src/transport-isolation.test.ts assert the isolation.

Affected versions >=1.4.2, <1.7.0 are deprecated on npm. Upgrade to 1.7.0 or later.

Workaround

If upgrading is not immediately possible, run in STDIO transport (unset TRANSPORT=http) or stop the HTTP server.

Credit

Reported independently by @232-323 and @2REBCat (tested against 1.6.0). The same root cause was found and fixed concurrently by the maintainer during a security audit, shipped in 1.7.0. All parties are credited as finders.

Note on severity

A connected client could read other clients' conversation history (C:H), inject messages into their sessions (I:L), and clear or delete other clients' sessions (A:L). Scope is unchanged: the impact stays within the application's own authorization boundary, which is a cross-tenant authorization bypass, so S:U is correct.