# Our MCP server is built on the official TypeScript SDK and the October 2026 advisories just reached NVD (shared transports leaking between clients, tokens for other services accepted, memory exhaustion). Which version fixes them, and is bumping the package enough?

**Short answer:** Upgrade to @modelcontextprotocol/sdk 1.32.0 or later on 1.x, or @modelcontextprotocol/server 2.3.0 or later on 2.x (plus @modelcontextprotocol/express 2.0.2 if you use it), but for three of the four server-side fixes the version bump alone doesn't close the hole. The shared-transport fix (GHSA-jm63-cq47-j5jp, CVE-2026-111770) makes the SDK refuse to be shared, so an app that built one transport or McpServer at startup starts failing with ALREADY_CONNECTED until you build one per request or per session. The token-audience fix (GHSA-rvq5-wwqv-78pq, CVE-2026-111771) adds an expectedResource setting that is off by default, and the memory-exhaustion fix (GHSA-46jr-4wx8-v453, CVE-2026-111768) adds a maxToolInputElements option that is also off by default; each advisory says in bold that upgrading alone changes nothing. Only the request size and batch limits (GHSA-f897-62hf-6gxq, fixed in sdk 1.30.1 and server 2.1.0) switch on by themselves: bodies over 4 MiB get 413 and batches over 100 messages get 400. stdio-only servers aren't affected by any of the four.

## Checklist
1. Run npm ls @modelcontextprotocol/sdk @modelcontextprotocol/server @modelcontextprotocol/express @modelcontextprotocol/node @modelcontextprotocol/hono @modelcontextprotocol/server-legacy and write down every version you actually ship, including ones pulled in by other packages.
2. Upgrade to sdk 1.32.0 or later (1.x), or server 2.3.0 or later with express 2.0.2, node 2.1.0 and hono 2.0.1 or later for whichever of those you have installed (2.x). server-legacy needs 2.3.1 or later for the audience fix.
3. Search your code for a transport or McpServer created once at module level and reused across HTTP requests. Replace it with createMcpHandler() and a factory that builds a new McpServer on every call, a new server and transport inside the request handler, or one server and transport per session with sessionIdGenerator set.
4. Turn on the audience check in two places at once: pass expectedResource (the URL your authorization server puts in tokens for your server) to requireBearerAuth(), and return the token's audience from verifyAccessToken() as AuthInfo.resource. With only the first change, every request gets 401.
5. If you can't upgrade yet, reject any token whose aud doesn't include your server inside verifyAccessToken(). The advisory says that closes the audience issue on every version.
6. Set maxToolInputElements just above the largest input your tools need, for example new McpServer(info, { maxToolInputElements: 10_000 }). It counts array elements and object keys in a call's arguments; a call over the limit gets an isError: true result.
7. Lower maxRequestBodySize to what your tools need, on the transport or createMcpHandler(). If you parse the body yourself with express.json() or Fastify, set that parser's limit too, and remember a body parser doesn't limit JSON-RPC batch length.
8. Add a test that sends two clients' requests with the same JSON-RPC id at the same time and checks each gets only its own response, a test that a token minted for another service gets 401, and a test that an oversized array argument is refused.

## What do the October 2026 MCP TypeScript SDK server advisories fix, and which fixes are off by default?
- GHSA-jm63-cq47-j5jp (CVE-2026-111770, high, published October 15, 2026) affects @modelcontextprotocol/server 2.0.0 through 2.2.0. An HTTP server could deliver one client's responses and notifications to another when clients shared one stateless transport or one McpServer or Server instance, because messages were matched to a connection by JSON-RPC id alone and SDK clients number requests from 0, so ids collide in normal use. The advisory notes that the README examples for the hono, express, fastify and node packages showed that pattern until this release. Not affected: createMcpHandler() with a factory that builds a new server per call, stdio servers, and @modelcontextprotocol/sdk 1.26.0 and later.
- GHSA-rvq5-wwqv-78pq (CVE-2026-111771, moderate, published October 5, 2026): the SDK's server-side bearer authentication had no way to check a token's audience, so where one authorization server issues tokens for several services, a valid token for another service was also accepted. You're affected if you use requireBearerAuth() or verifyBearerToken(), your authorization server also issues tokens for other services, and your verifyAccessToken() doesn't check aud itself. Affected: sdk 1.6.0 through 1.31.0, server 2.0.0 through 2.2.0, express 2.0.0 through 2.0.1 and server-legacy 2.0.0 through 2.3.0.
- GHSA-46jr-4wx8-v453 (CVE-2026-111768, high, published October 15, 2026): servers put no limit on how many array elements and object keys they validated in one request, so a single request inside the default 4 MiB limit could exhaust memory and abort the process with JavaScript heap out of memory, with no credentials needed unless you authenticate before the SDK. The risk is highest for McpServer tools whose input contains an array or a record. Affected: sdk 1.3.0 through 1.31.0 and server 2.0.0 through 2.2.0. If you can't upgrade, set maxRequestBodySize, which needs sdk 1.30.1 or server 2.1.0; below that, use a reverse proxy.
- GHSA-f897-62hf-6gxq (high, published October 15, 2026) is the one that works on upgrade: HTTP server transports had no limit on POST body size or JSON-RPC batch length, and one long batch could block a server from serving anyone else. sdk 1.30.1 and server 2.1.0, node 2.1.0 and hono 2.0.1 add the 4 MiB and 100-message limits by default; raise maxRequestBodySize only if your clients really send larger bodies.

## Why does an MCP server fail with ALREADY_CONNECTED after upgrading the TypeScript SDK?
- After the shared-transport fix, a second connect() on the same server rejects with ALREADY_CONNECTED and a stateless transport rejects its second request. That's deliberate: the advisory says the SDK now refuses to be shared, so an affected app fails requests after upgrading instead of silently crossing clients' data.
- The same code change fixes affected versions even before you upgrade, so it's worth doing first: build per request (simplest for stateless servers), use createMcpHandler() with a factory, or keep one server and transport per session. If you're also moving to the 2026-07-28 spec, which removes protocol-level sessions and makes every request self-describing, per-request construction is the natural fit.

## How do you test that the MCP SDK audience check and input limits are actually enabled?
- A green dependency scan only proves the version. For the audience fix, send a token issued by your authorization server for a different service and expect 401; if you get 200, expectedResource or AuthInfo.resource is missing. For the input bound, call a tool with an array argument larger than maxToolInputElements and expect an isError result, not a crash or a slow response.
- For the shared transport, run two clients against one deployment at the same time, both starting at request id 0, and check neither ever sees the other's results. Keep those three tests in CI so a later refactor that reintroduces a module-level server, or drops the options, fails the build instead of shipping.

## Ask Rightshold (free, no key)
Add the MCP server https://www.rightshold.com/mcp to Claude, Cursor, ChatGPT, Grok or VS Code (one-click setup: https://www.rightshold.com/start?ref=seo), then ask: "I just upgraded my MCP server to the patched TypeScript SDK and switched to building a server per request. Check what my server serves now: has its tool list changed from what was recorded, and does any tool definition carry hidden text?"

```json
{
  "tool": "precall_check",
  "arguments": {
    "url": "<your server's https MCP URL>"
  }
}
```
- Free, no key. It probes the tool definitions your server serves now and compares them with any recorded fingerprint (unchanged, changed with a plain diff, or unreachable, never reported as unchanged), scans them for invisible text and reports standing security flags and tool-name collisions. An SDK upgrade shouldn't change your tools; if the diff shows it did, review that before your users' clients flag it. Checking a server doesn't register it.
- It doesn't read your package versions, test the audience check, the input bound or the shared-transport fix, or send traffic as two clients. Those are the three tests above, and they belong in your own CI.

_Rightshold reports what an MCP endpoint serves and what it has on record about it. It doesn't scan your code, dependencies or configuration, and an unchanged answer isn't a finding that a server is patched. Advisory details are as published by the MCP TypeScript SDK maintainers on GitHub and read on November 11, 2026; advisories get updated, so confirm fixed versions on the linked pages before you upgrade._

## Sources
- [MCP TypeScript SDK: GHSA-jm63-cq47-j5jp, shared transport or server instances delivered one HTTP client's messages to another (CVE-2026-111770)](https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-jm63-cq47-j5jp)
- [MCP TypeScript SDK: GHSA-rvq5-wwqv-78pq, server bearer authentication accepted tokens issued for another service (CVE-2026-111771)](https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-rvq5-wwqv-78pq)
- [MCP TypeScript SDK: GHSA-46jr-4wx8-v453, one HTTP request within the default size limit could exhaust server memory (CVE-2026-111768)](https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-46jr-4wx8-v453)
- [MCP TypeScript SDK: GHSA-f897-62hf-6gxq, HTTP server transports did not limit request body size or JSON-RPC batch length](https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-f897-62hf-6gxq)
- [NX Dev Solutions: MCP vulnerability roundup, November 2026 server CVEs (November 10, 2026)](https://nxdevsolutions.com/blog/mcp-server-cve-november-2026)

## Related
- [MCP OAuth wrong-audience tokens: what they are and how to defend](https://www.rightshold.com/answers/mcp-oauth-wrong-audience-tokens)
- [Can an MCP session ID or state handle be used to authenticate a user?](https://www.rightshold.com/answers/can-an-mcp-session-id-or-state-handle-be-used-to-authenticate-a-user)
- [How to cap MCP tool output size to prevent context flooding](https://www.rightshold.com/answers/how-to-cap-mcp-tool-output-size-to-prevent-context-flooding)
- [Pinning MCP server versions and reviewing changes before you upgrade](https://www.rightshold.com/answers/how-to-pin-mcp-server-versions-and-review-changes-before-upgrading)

_Not legal advice. Updated 2026-11-11. JSON: https://www.rightshold.com/answers/which-mcp-typescript-sdk-version-fixes-the-october-2026-server-advisories-and-why-upgrading-isnt-enough.json_