We're about to expose our MCP server over Streamable HTTP. What stops one anonymous client from knocking it offline with a broken or oversized request, or from grabbing the server so nobody else can connect, and what limits should the HTTP layer enforce before a request reaches the MCP SDK?

What should I check, step by step?

1. Cap the request body by counting bytes as chunks arrive, not by trusting Content-Length; a chunked request has none. Stop buffering at the cap and answer 413.

2. Wrap JSON parsing of every request in a local try/catch and answer 400 with a short error. One bad request should never reach the process-level crash handler.
3. Give each client session its own server and transport, kept in a bounded map, or run stateless so no session exists. Never share one stateful transport across all HTTP clients.
4. Cap total sessions and sessions per client, close sessions that go idle, and set request, header and keep-alive timeouts on the HTTP server so a slow sender can't hold a connection open.
5. Rate limit per client and add a process-wide ceiling, because a per-IP limit alone can be spread across many source addresses. Derive the client address only from your own proxy's forwarding header.
6. Run under a supervisor that restarts the process, with a memory limit, so a crash you didn't foresee costs seconds, not an outage that lasts until someone notices.
7. Require a credential before any of this is reachable from another machine; bind to 127.0.0.1 when only local clients need it.
8. Add tests that send a truncated JSON body, a body one byte over the cap, and two initialize requests from different clients, and assert 400, 413 and two working sessions.

How did one malformed or oversized request crash the @tsparticles/mcp-server HTTP mode (CVE-2026-76892, CVE-2026-63655, CVE-2026-76893)?

The HTTP mode of @tsparticles/mcp-server read POST /mcp bodies by pushing every data chunk into an array, joining them and calling JSON.parse on the result, then handing that to the SDK transport. GHSA-4p8p-pjpq-2w7h (CVE-2026-76892, CWE-248, CVSS 4.0 8.7) says the parse sat outside a request-local error boundary: the truncated body {"jsonrpc": ended the process in 3 out of 3 runs, and the service stayed down until an outside supervisor restarted it. It affects 4.3.0 and earlier and is fixed in 4.3.1, which answers 400 for invalid JSON.

• GHSA-447x-qqwf-m7xq (CVE-2026-63655, CWE-400, CVSS 3.1 7.5) covers the same handler from the other side: no cumulative size check, no Content-Length check and no 413 anywhere in the server. The report streamed a 300 MB chunked body at a container limited to 256 MB; after about 209 MB Docker's OOM killer ended the process. It notes the project's Dockerfile started the server with --port 3000, which bound HTTP mode to all interfaces, so anyone running the image was exposed without opting in. It is fixed in 4.3.1.
• GHSA-h7c4-q426-7jh9 (CVE-2026-76893, CWE-400, CVSS 4.0 6.9) is a different kind of denial: the server created one stateful StreamableHTTPServerTransport and reused it for every request. The first client's initialize got a session id; a second, independent initialize got HTTP 400 "Invalid Request: Server already initialized". An anonymous client that connects first keeps every legitimate client out until a restart. The advisory's remedy is a transport per session or a bounded map from session id to transport, and it is fixed in 4.3.2.

What body, session, timeout and rate limits should an MCP server's HTTP mode enforce?

The project's current HTTP server code (main branch, read November 13, 2026) is a compact example of the limits above. It counts body bytes as they arrive, stops buffering past 1 MB and answers 413 once the body has been read, and answers 400 "Invalid JSON" when parsing throws. Each initialize gets a new server and transport pair kept in a map, with at most 500 concurrent sessions and 10 per client, and sessions idle for 30 minutes are closed by a sweep every 5 minutes.

• It also sets a 30-second request timeout and a 15-second header timeout, rate limits each client to 120 requests a minute with a process-wide ceiling of 2,000, and its own comments say the per-IP limit is easy to spread across many addresses, which is why the global ceiling exists. It reads X-Forwarded-For only when the connecting peer is a configured trusted proxy, and it refuses to start on a non-loopback host without an auth token.
• Those numbers suit a small tool server; pick yours from your real request sizes and client counts. The pattern is what carries over: every limit is enforced before the SDK sees the request, and every rejection is a bounded response, not a crash.

Does the MCP 2026-07-28 stateless core stop one client from grabbing an MCP server's session?

The 2026-07-28 MCP specification retires the initialize/initialized exchange and the Mcp-Session-Id header (SEP-2575, SEP-2567). Each request carries its protocol version, client identity and capabilities itself, so any request can land on any server instance, and there is no shared protocol session for a first caller to claim. A server that also serves clients on older protocol versions still creates sessions for them, so keep the per-session limits until you drop those versions.

• Streamable HTTP requests on the new version must carry Mcp-Method and Mcp-Name headers (SEP-2243). The project announcement says gateways, rate limiters and WAFs can route and meter on those headers instead of parsing JSON bodies, which lets you reject or throttle a request before your server reads its body. Your server still has to cap and parse that body safely when it does arrive.