Three denial-of-service flaws found in tsParticles MCP server

Three vulnerabilities in the HTTP mode of @tsparticles/mcp-server, the Model Context Protocol server published by the tsParticles project, were disclosed in GitHub advisories dated 9 November 2026. All three allow an unauthenticated remote attacker to deny service to legitimate users. Two of the three were verified on version 4.3.0, according to the advisories, and one of those remains present in version 4.3.1 and in the current main branch.

The first issue, tracked as CVE-2026-63655, concerns how the server reads request bodies. According to the advisory, the handler for POST /mcp pushes every incoming data chunk into an in-memory buffer array with no size limit, no Content-Length check and no 413 Payload Too Large response, before passing the result to JSON.parse. An attacker can stream an arbitrarily large body and exhaust the Node.js process memory. The advisory says this was confirmed in testing: a 300 MB stream sent to a container limited to 256 MB caused Docker's out-of-memory killer to terminate the process after roughly 209 MB had been received, with the container state recorded as OOMKilled.

The advisory notes that the official Docker image runs the server in HTTP mode by default, listening on port 3000 on all network interfaces, with no authentication on the endpoint. That means, in the advisory's words, any operator running the official image is exposed without changing any configuration. Recovery requires restarting the container. The suggested fix is to count received bytes and destroy the request once a threshold such as 1 MB is passed.

The second issue, CVE-2026-76892, uses the same handler but needs far less traffic. Because the JSON.parse call is not wrapped in a try/catch block, a single malformed request body — the advisory gives the example {"jsonrpc": — makes the async handler throw and the Node.js process exit with a SyntaxError. The advisory says this was reproduced in three of three runs on version 4.3.0, and that version 4.3.1 appears to fix it by returning an HTTP 400 response for invalid JSON. The service stays down until an external supervisor restarts it.

The third issue, CVE-2026-76893, is a design problem rather than a crash. The server creates one stateful StreamableHTTPServerTransport object and reuses it for every client. According to the advisory, the first anonymous client to call initialize claims that shared state, and every later client receives an HTTP 400 error reading "Invalid Request: Server already initialized". That was also observed in three of three runs. The first session keeps working; everyone else is locked out until the process restarts. The advisory says the same singleton transport pattern is still present in version 4.3.1 and current main, and recommends creating a transport per session, or keeping a bounded map of session IDs to transports.

None of the three flaws directly affects confidentiality or integrity, the first advisory says. All three require only network access to the MCP endpoint.