Skip to main content
VulnerabilityPublished

CVE-2026-76893: tsParticles · A single anonymous MCP session can monopolize HTTP mode and deny new clients

Affects @tsparticles/mcp-serverSource GCVE Database

0
Compare
Authoritative record:CVE-2026-76893· Medium 6.9

Not known to be exploited · CVSS 6.9 Medium : upgrade to 4.3.2 when convenient.

Data as of 9 Nov 2026, 23:24 UTC

CVSS 4.0 base score
6.9Medium
How severe the flaw is on the 0–10 CVSS scale.

Thin evidence

One scorer or none
CVSS scores by source
CNA (GitHub_M)CVSS 4.06.9
EPSS
0.2% chance of exploitation in 30 days – higher than 21% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 4.3.2
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 4 Nov 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 9 Nov 2026.

What to do

Upgrade @tsparticles/mcp-server to 4.3.2.

Affected software

ProductAffectedFixed in
npm@tsparticles/mcp-serverAffected
  • <4.3.2
Fixed in
  • 4.3.2

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

## 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.

References

Community reviews

Loading reviews…