CVE-2026-76893 — @tsparticles/mcp-server

Summary

The HTTP mode of @tsparticles/mcp-server creates a single stateful StreamableHTTPServerTransport instance and reuses it for all clients. The first anonymous client that initializes the MCP endpoint claims the shared transport state, and later clients cannot create their own sessions.

This was verified on v4.3.0 at commit 0266d469aa2d719cb66a9c6bf09aded4186ec17c. The same singleton transport pattern is still present in v4.3.1 and current main.

Affected Code

The server creates one shared transport before accepting requests:

const transport = new StreamableHTTPServerTransport({
  sessionIdGenerator: () => randomUUID(),
});

const httpServer = createServer(async (req, res) => {
  ...
  await transport.handleRequest(req, res, parsedBody);
});

Because the same transport object is reused across all requests, the first successful initialize call changes the state for all later clients.

Reproduction

Send two independent initialize requests without a prior mcp-session-id.

First request:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"first-client","version":"1.0.0"}}}

Second request:

{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"second-client","version":"1.0.0"}}}

Observed result in 3 out of 3 runs:

first response: HTTP 200 with mcp-session-id
second response: HTTP 400
{"jsonrpc":"2.0","error":{"code":-32600,"message":"Invalid Request: Server already initialized"},"id":null}

Impact

An unauthenticated remote client can win the first-session race and prevent all later legitimate clients from establishing new MCP sessions until the process is restarted. The first session remains functional, but new clients are denied service.

Recommendation

Create a transport per session or maintain a bounded session-id-to-transport map. Do not reuse one stateful transport instance for all HTTP clients.