Analysis · DiggingBeagle record
An MCP server needs three different boundaries, not one version number
Three maintainer advisories separate cross-client response identity, network-byte and batch limits, and tool-argument validation work.
- Published
- Oct 17, 2026
Overview
A model can make a legitimate MCP tool call and still receive someone else's response. Another client can send a large protocol batch that monopolizes a server. A third request can stay below the HTTP size limit yet exhaust memory during argument validation. Three official TypeScript SDK advisories published on October 15 describe these distinct failures, and they cannot be fixed by testing one package version in isolation.
The three boundaries
| Boundary | Trigger in the maintainer report | Relevant remediation | Independent regression check |
|---|---|---|---|
| Client identity | Multiple HTTP clients share a server or transport instance; their JSON-RPC request IDs collide | @modelcontextprotocol/server 2.3.0 plus fresh server/transport per request or session |
Overlapping IDs never redirect responses or notifications to a different client |
| Protocol admission | Unbounded HTTP bodies or JSON-RPC batch lengths reach an adapter | Fixed SDK, Node and Hono adapter versions; body and batch limits | Oversized request rejected while valid concurrent requests still complete |
| Tool-argument work | A body below the byte cap contains many keys or array elements | Fixed SDK plus explicitly configured maxToolInputElements |
Deep or dense arguments stop before heap exhaustion |
Authentication does not bind a response to its owner
The cross-client report identifies a routing fault: under a shared HTTP server/transport, different SDK clients could issue the same JSON-RPC id and receive misdirected messages. Authentication at the front door was not enough to keep the response attached to its original connection. The 2.3.0 change refuses unsafe instance reuse. Applications written with a singleton handler must also change their lifetime model, otherwise an upgrade may turn the leak into rejected requests rather than a functioning service. stdio-only servers and correctly separated handlers are outside that described scope.
A byte limit does not bound protocol work
The HTTP admission advisory describes missing default bounds for body size and batch length in affected transport and adapter packages. Maintainers specify fixed combinations beginning with 1.30.1 for the SDK, 2.1.0 for server and Node, and 2.0.1 for Hono. In the patched defaults, a body over 4 MiB receives HTTP 413 and a batch of more than 100 messages receives HTTP 400. The application may set different supported budgets, but must do so knowingly at the actual entry point.
The argument-complexity advisory covers another route to exhaustion. JSON/schema validation can perform expensive work on a large number of very small elements even when the full HTTP request is under 4 MiB. In SDK 1.32.0 and server 2.3.0, the maxToolInputElements control becomes available but remains off by default. It counts argument object keys and array elements. The maintainer's example of 10,000 is a configuration illustration, not a safe universal limit; it does not replace a separate byte cap.
What the evidence actually proves
These are maintainer-documented vulnerabilities with identified triggering conditions and patches. They do not establish how many public MCP deployments used shared state, how many were attacked or whether any private customer data was taken. A defensible deployment check must use the precise installed SDK and adapter versions, exercise simultaneous authenticated connections, and test both network size and post-parse validation work. One green model benchmark, a patched dependency declaration or a passing single-client demo cannot cover all three boundaries.