CVE-2026-55605: Missing Authentication in @arikusi/deepseek-mcp-server HTTP Transport Endpoint

The self-hosted HTTP transport mode of the @arikusi/deepseek-mcp-server package facilitates communication between external clients and the Model Context Protocol (MCP) daemon. This server is designed to securely hold and utilize administrative keys, such as the DEEPSEEK_API_KEY, to perform downstream model interactions. In versions starting at 1.4.2 and extending up to 1.8.0, the system exposes its main JSON-RPC communications hub without verifying the identity of the incoming request client.

Because the daemon instantiates its core HTTP application through the createMcpExpressApp function without configure-time middleware, any network-accessible endpoint can route arbitrary payloads directly to the controller. The underlying system classifies this structural omission under CWE-306, representing a critical missing authentication flaw on a component designed to handle powerful automation tools.

When deployed on a public-facing network interface or exposed via configuration files such as Docker Compose with wildcard bindings (0.0.0.0), the system is completely vulnerable to unauthorized remote users. This enables external clients to issue complex API requests, resulting in resource exhaustion and financial loss for the endpoint operator.

The core issue stems from how the HTTP listener is configured in src/transport-http.ts. The transport module configures an Express web server to receive HTTP POST payloads containing JSON-RPC 2.0 instructions and convert them into MCP actions. In the vulnerable release range, the application configures the server instance via createMcpExpressApp without defining an authentication provider or registering request verification handlers on the /mcp route.

Without an active security middleware check, the Express pipeline forwards all HTTP POST packets directly to the internal JSON-RPC parser. This process permits any visitor to establish a session state and obtain a valid session identifier. Once this state is active, the transport layer allows full read and write execution rights to any exposed model-tool capabilities.

Furthermore, the default configuration within the project's containerization templates instructs the runtime environment to bind the socket listener to all available network interfaces. Because this default behavior operates without verifying loopback limits or enforcing credential headers, the application exposes its capabilities on the external port 3000 to any internet-facing router.

Analyzing the vulnerable code path in src/transport-http.ts highlights the lack of authorization layers prior to routing requests to the JSON-RPC engine. In the unpatched versions, the server initialization logic creates the Express application and defines the /mcp endpoint directly, skipping any conditional token checks:

// Vulnerable: Express route handler lacks authorization middleware
export function createHttpApp(serverFactory: () => McpServer) {
  const app = createMcpExpressApp({ host: '0.0.0.0' });
  // ... routing is established directly with no auth middleware ...
  return app;
}

The patched version implemented in commit dab07ed93ddde0ab219d4cb7066785847db53a32 updates the application structure to perform timing-safe string comparison verification. The following Mermaid diagram shows the flow of request processing after the application of the patch:

To remediate the vulnerability, the development team integrated constant-time string comparison methods to evaluate the HTTP_AUTH_TOKEN environment variable against incoming headers. If the expected variable is set, any request lacking the matching bearer string receives a 401 Unauthorized response immediately, stopping execution before the JSON-RPC parser processes the request body:

// Patched: Implementation of bearer validation and host verification
if (authToken) {
  const expected = `Bearer ${authToken}`;
  app.use('/mcp', (req, res, next) => {
    const provided = req.headers['authorization'];
    if (typeof provided === 'string' && timingSafeStringEqual(provided, expected)) {
      next();
      return;
    }
    res.status(401).json({
      jsonrpc: '2.0',
      error: { code: -32001, message: 'Unauthorized' },
      id: null,
    });
  });
}

Exploiting this vulnerability does not require complex payloads or cryptographic bypasses because the target endpoint does not require any credentials. An actor begins by scanning network ranges for port 3000 or monitoring server responses for standard /health endpoints. An active, vulnerable server replies with system metadata and confirmed version indices.

After locating a target, the caller transmits an initialization instruction formatted as a standard JSON-RPC 2.0 object to the /mcp endpoint. The server processes this unauthenticated payload, instantiates a session tracking record, and returns a unique identifier in the mcp-session-id response header. This sequence establishes a persistent session state without credentials:

POST /mcp HTTP/1.1
Host: target:3000
Content-Type: application/json
 
{
  "jsonrpc": "2.0",
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-03-26",
    "capabilities": {},
    "clientInfo": { "name": "exploit-test", "version": "1.0" }
  },
  "id": 1
}

Using the acquired session ID, the user can invoke backend commands such as tools/call. Because the server processes requests using its local DEEPSEEK_API_KEY, the attacker's prompt is forwarded to the DeepSeek upstream infrastructure, causing direct utilization of the administrator's API allocation.

The security impact of CVE-2026-55605 centers on unauthorized resource consumption and the potential compromise of sensitive operations. Because the server uses a pre-configured backend token to interact with DeepSeek, external actors can run expensive LLM requests at the owner's expense. This can quickly exhaust API quotas or cause significant financial charges on pay-as-you-go developer accounts.

In addition to financial impact, the vulnerability exposes metadata about the server's environment and previous operations. Unauthenticated users can list active sessions and retrieve details about tools integrated with the platform, exposing internal workflows or directory layouts depending on the active tool capabilities.

While the flaw does not directly allow arbitrary local code execution on the underlying host, it bypasses the primary security perimeter of the server. This makes the vulnerability highly critical for self-hosted instances connected to corporate networks or exposed directly to the public internet.

Remediation requires upgrading the NPM package dependency @arikusi/deepseek-mcp-server to version 1.8.0 or later. This update changes the default network binding interface from 0.0.0.0 to 127.0.0.1 and integrates token-based verification checks into the HTTP routing path.

Administrators must configure the HTTP_AUTH_TOKEN environment variable to enforce authentication. This token must be a long, randomly generated string, and clients must supply it in the Authorization header of all HTTP requests as a bearer token:

# Example of setting a secure authorization token
export HTTP_AUTH_TOKEN="$(openssl rand -hex 32)"

If upgrading immediately is not possible, deploy defensive network rules to restrict access. Configure firewalls to block port 3000 from external IP addresses, or bind the application container strictly to the loopback interface within Docker configuration templates.