CVE-2026-76893

tsParticles is a TypeScript library for creating highly customizable particle animations. Prior to 4.3.2, the HTTP mode of @tsparticles/mcp-server reuses one stateful StreamableHTTPServerTransport for every client. An unauthenticated client that sends the first initialize request without an mcp-session-id claims the shared transport state, causing later independent clients to receive Server already initialized and preventing them from establishing sessions until the process restarts. The first client's session remains functional. This issue is fixed in version 4.3.2.

tsParticles: A single anonymous MCP session can monopolize HTTP mode and deny new clients

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.

tsParticles is a TypeScript library for creating highly customizable particle animations. Prior to 4.3.2, the HTTP mode of @tsparticles/mcp-server reuses one stateful StreamableHTTPServerTransport for every client. An unauthenticated client that sends the first initialize request without an mcp-session-id claims the shared transport state, causing later independent clients to receive Server already initialized and preventing them from establishing sessions until the process restarts. The first client's session remains functional. This issue is fixed in version 4.3.2.

tsParticles is a TypeScript library for creating highly customizable particle animations. Prior to 4.3.2, the HTTP mode of @tsparticles/mcp-server reuses one stateful StreamableHTTPServerTransport for every client. An unauthenticated client that sends the first initialize request without an mcp-session-id claims the shared transport state, causing later independent clients to receive Server already initialized and preventing them from establishing sessions until the process restarts. The first client's session remains functional. This issue is fixed in version 4.3.2.

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.