CVE-2026-55604: Authorization Bypass via Global Session Singleton in @arikusi/deepseek-mcp-server

The @arikusi/deepseek-mcp-server package functions as a Model Context Protocol (MCP) server designed to facilitate integration with DeepSeek V4 models. It enables applications to communicate with the DeepSeek API through a defined set of tools, prompts, and resources. The server exposes capabilities to manage multi-turn chat sessions and retrieve conversational history. This is accomplished via two supported transport layers: STDIO and Streamable HTTP.

When deployed in Streamable HTTP transport mode (TRANSPORT=http), the server acts as a multi-tenant web service. This design allows multiple concurrent remote clients to connect and maintain isolated conversational sessions. However, the architectural design failed to account for multi-tenancy requirements at the storage layer. A shared component was used across all incoming network connections without boundary isolation.

This design flaw results in a critical vulnerability classified under CWE-639: Authorization Bypass Through User-Controlled Key. Because the backend does not enforce connection-level ownership of sessions, any client connecting to the HTTP service can access or modify data belonging to other clients. The attack surface is exposed directly through the JSON-RPC endpoints on the self-hosted HTTP server port.

The root cause of this vulnerability lies in the implementation of the SessionStore class inside src/session.ts. In versions prior to 1.7.0, the system utilized a process-global singleton pattern. This pattern was instantiated via a static getInstance() method that returned a single, shared in-memory instance of SessionStore containing a map of all conversational sessions.

While this pattern is secure in the single-tenant STDIO transport mode—where a dedicated OS process is spawned per client—it introduces severe security implications in multi-tenant environments. Under the HTTP transport configuration, the server runs as a single, long-lived process handling multiple concurrent remote TCP connections. Consequently, every client connection shares the exact same instance of the SessionStore memory map.

Furthermore, the server relies entirely on user-supplied identifiers to perform lookups within the shared map. The deepseek_chat tool retrieves sessions by querying SessionStore.getInstance().get(validated.session_id) using the parameter provided in the client's RPC request. The application performs no session-to-connection binding, token verification, or cryptographic validation to confirm that the requesting client is the legitimate owner of the target session_id. Consequently, knowledge of a session ID is the sole requirement to access the corresponding conversation context.

A comparison of the vulnerable and patched versions shows how the singleton was eliminated and replaced with per-connection scoping. In the vulnerable codebase, src/session.ts defined SessionStore as a class with a private constructor and a static instance variable. This pattern is shown below:

// Vulnerable: src/session.ts (Version < 1.7.0)
export class SessionStore {
  private static instance: SessionStore | null = null;
  private sessions = new Map<string, Session>();
  private requestCounter = 0;
 
  private constructor() {}
 
  static getInstance(): SessionStore {
    if (!SessionStore.instance) {
      SessionStore.instance = new SessionStore();
    }
    return SessionStore.instance;
  }
}

The patch implemented in commit 9fd514292d23d59ca1434b01f019aca6ef4356f9 refactored the class to allow standard instantiation. It removed the private constructor and static helpers:

// Patched: src/session.ts (Version >= 1.7.0)
export class SessionStore {
  private sessions = new Map<string, Session>();
  private requestCounter = 0;
 
  constructor() {} // Public constructor allowing multiple instances
}

In the server entry point (src/index.ts), the initialization logic was updated to scope the session store based on the active transport mode. Under the HTTP transport, a fresh instance of SessionStore is constructed for each incoming connection factory call, ensuring cryptographic isolation between tenants:

// Patched: src/index.ts (Version >= 1.7.0)
if (config.transport === 'http') {
  // Dynamic factory creates a unique SessionStore per SSE stream
  const serverFactory = () => {
    const s = createServer();
    const sessionStore = new SessionStore(); // Fresh instance
    registerAllTools(s, deepseek, sessionStore); // Bound exclusively to this server instance
    registerAllPrompts(s);
    registerAllResources(s);
    return s;
  };
}

An attacker can exploit this vulnerability with standard HTTP/SSE tools by sending JSON-RPC payloads directly to the vulnerable server. The exploitation process involves three logical phases: session enumeration, context exfiltration, and optional denial of service. The attack requires no prior authentication and works against any default installation running in HTTP mode.

First, the attacker queries the deepseek_sessions tool using the list action. Because the tool retrieves data from the global singleton, it returns a list of all active session identifiers stored in the memory map of the server process. This allows the attacker to identify victim session IDs without needing to brute-force UUIDs.

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "deepseek_sessions",
    "arguments": {
      "action": "list"
    }
  },
  "id": 100
}

After harvesting a valid target session_id, the attacker invokes the deepseek_chat tool. The attacker includes the victim's session_id alongside a crafted user message designed to prompt the model to dump its context. The server loads the corresponding history and passes it to the upstream LLM, which processes the context and returns the compiled conversation history directly to the attacker.

The security impact of this vulnerability is high, specifically threatening the confidentiality and integrity of private LLM interactions. Since these servers often handle internal codebases, proprietary business plans, or raw configuration parameters, exposing the complete multi-turn conversation history represents a significant data exposure risk. Attackers can monitor active chats in real time to capture secrets as they are entered.

The vulnerability also impacts session integrity. Because attackers can append messages to an active session, they can perform prompt injection attacks or introduce malicious payloads into the LLM context. This can trick the LLM into generating malicious commands or code that the victim might execute within their development environment.

From an availability perspective, the deepseek_sessions tool supports a clear action. This allows an unauthenticated attacker to clear the global session map, terminating all active chats across the server. This causes immediate service disruption and context loss for all active tenants.

The CVSS v3.1 vector string is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L, yielding a base score of 8.6. The low complexity and lack of required privileges mean the vulnerability can be easily automated at scale. This threat profile is reflected in the high confidentiality score.

The primary remediation strategy is upgrading @arikusi/deepseek-mcp-server to version 1.7.0 or higher. This upgrade replaces the global singleton pattern with per-connection instantiations of the SessionStore, preventing cross-session communication and context exposure.

For environments where immediate upgrading is not feasible, several defensive workarounds should be applied. Administrators should restrict the transport configuration to stdio if the service is only used locally. If HTTP mode is required, the service must be bound to localhost or protected by an authentication proxy, such as a VPN or a reverse proxy with TLS client certificates.

Organizations can detect exploitation attempts by monitoring server traffic logs for JSON-RPC calls targeting the deepseek_sessions tool. Frequent list or clear requests, particularly those originating from unexpected IP addresses, indicate potential scanning or exploitation. Security teams should implement the following YARA rule to scan local server logs for evidence of session harvesting or clearing:

rule DeepSeek_MCP_Session_Bypass {
    meta:
        description = "Detects JSON-RPC payloads used to exploit CVE-2026-55604"
        author = "Security Analyst"
        reference = "CVE-2026-55604"
        date = "2026-07-09"
    strings:
        $rpc = "\"jsonrpc\""
        $method = "\"method\": \"tools/call\""
        $tool = "\"name\": \"deepseek_sessions\""
        $action_list = "\"action\": \"list\""
        $action_clear = "\"action\": \"clear\""
    condition:
        $rpc and $method and $tool and ($action_list or $action_clear)
}