MCP TypeScript SDK 1.32.0: Four Advisories, Two High, and Fixes That Need Config

Four security advisories for the MCP TypeScript SDK were reviewed by GitHub on October 20, 2026, and one release line fixes them: @modelcontextprotocol/sdk 1.32.0, or the 2.3.0 packages on the 2.x line. Two are rated high, two moderate. If you run an MCP server over HTTP, or build an MCP client that follows redirects or uses OAuth, check your versions today. Two of the four fixes ship switched off, so upgrading alone changes nothing until you set an option.

This is the second batch of SDK advisories this month. On October 13 we covered the OAuth issuer flaw, CVE-2026-104850, fixed in 1.31.0. These four build on that release: if you stopped at 1.31.0, you are still exposed to all of them.

The four advisories at a glance

The advisories were published in the modelcontextprotocol/typescript-sdk repository between October 2 and October 15, and entered the GitHub Advisory Database on October 20, 2026. Reporters are credited by handle on each advisory page.

CVE-2026-111768: one request can exhaust server memory

What it does. According to the advisory, servers put no limit on how many array elements and object keys they validated in a single request. One HTTP request within the default 4 MiB size limit could exhaust the server's memory, and the Node.js process aborted with JavaScript heap out of memory. The CVSS vector is AV:N/AC:L/PR:N/UI:N with high availability impact: network reachable, no credentials, no user interaction. The weakness is CWE-770, allocation of resources without limits.

Who is affected. Servers reachable by clients you do not fully trust over HTTP. The risk is highest for McpServer tools whose input contains an array or a record. The advisory is explicit that stdio-only servers are not affected, and that no credentials are needed unless you authenticate requests before they reach the SDK.

Why this matters for agents. An MCP server is often a thin wrapper around something an agent depends on: a ticket system, a database, an internal API. If it falls over on a crafted request, the agent loses that tool, and a crashing process can also lose in-flight work. This is availability, not data theft, but a flapping server is also the moment people start loosening limits to get things working again.

The fix needs two settings. The advisory states plainly: "Upgrading alone changes nothing." The patched versions add an McpServer option, maxToolInputElements, that is off by default. It counts array elements and object keys in a call's arguments, and a call over the limit gets an isError: true result. The advisory's example is:

new McpServer(info, { maxToolInputElements: 10_000 })

Set it just above the largest input your tools legitimately need. Then lower the request size limit to what your tools need. The option covers tool arguments only; the size limit covers everything else. Set maxRequestBodySize on the transport or on createMcpHandler(). If you parse the body yourself, for example with express.json() or Fastify, set that parser's limit instead.

If you cannot upgrade yet, do the second change. maxRequestBodySize needs @modelcontextprotocol/sdk 1.30.1 or @modelcontextprotocol/server 2.1.0; below that, put the limit in a reverse proxy.

CVE-2026-111767: experimental tasks were not tied to a session

What it does. The experimental tasks feature (taskStore) did not check which session created a task. According to the advisory, clients sharing one InMemoryTaskStore could list, read and cancel each other's tasks. The CVSS vector is AV:N/AC:L/PR:N/UI:N with high confidentiality impact, which is why it scores 8.6. The weaknesses are CWE-639 (authorization bypass through a user-controlled key) and CWE-862 (missing authorization).

What that means in practice. A task is how a long-running tool call reports progress and results. If two users or two agents connect to the same server and the same store, one could enumerate the other's tasks, read their results, and cancel them. Anything a task result contained, such as query output or file contents, is exposed to whoever else is connected.

Who is affected. Only HTTP servers that pass taskStore to McpServer or Server, on @modelcontextprotocol/sdk 1.24.0 through 1.31.0. The 2.x packages are not affected. The advisory gives a quick test: if grep -ri taskstore --exclude-dir=node_modules . finds nothing, you are not affected.

Fix. Upgrade to 1.32.0, where each task is tied to the session that created it, so a client that starts a new session can no longer reach its earlier tasks. The advisory also says experimental tasks are deprecated, because the 2026-07-28 specification replaced them with a redesigned extension, and the best course is to stop using them. If you cannot upgrade, remove taskStore or create one InMemoryTaskStore per session.

CVE-2026-111771: bearer auth accepted tokens meant for another service

What it does. The SDK's server-side bearer authentication had no way to check that a token was issued for your server, its audience. Per the advisory, where one authorization server issues tokens for several services, a valid token for another service was also accepted by your MCP server. This is the classic confused-deputy pattern: a token that proves "this is user X" gets honoured by a service it was never meant for.

Who is affected. All three conditions must hold: your HTTP server uses requireBearerAuth() or verifyBearerToken(), your authorization server also issues tokens for other services, and your verifyAccessToken() does not check the token's aud claim itself. If you wrote your own audience check, you were already covered. The score is 6.8 (moderate) mainly because attack complexity is high and the attacker needs a low-privilege token, but confidentiality and integrity impacts are both rated high.

Affected and fixed versions differ per package: @modelcontextprotocol/sdk 1.6.0–1.31.0 → 1.32.0; @modelcontextprotocol/server 2.0.0–2.2.0 → 2.3.0; @modelcontextprotocol/express 2.0.0–2.0.1 → 2.0.2; @modelcontextprotocol/server-legacy 2.0.0–2.3.0 → 2.3.1.

The fix is opt-in. The patched versions add an expectedResource setting, off by default. Turn the check on with two changes together:

1. Pass the audience your authorization server puts in tokens for your server: requireBearerAuth({ verifier, expectedResource: new URL('https://mcp.example.com/mcp') }).
2. Return the token's audience from verifyAccessToken() as AuthInfo.resource, also a URL.

A token for another service then gets a 401. The advisory warns that with only the first change, every request gets a 401, so test before you deploy. If you cannot upgrade, reject any token whose aud does not include your server inside verifyAccessToken(); the advisory says that closes the issue on every version.

CVE-2026-111769: redirects re-sent custom headers and request bodies

What it does. The SDK's HTTP client transports and OAuth requests followed redirects to any origin. According to the advisory, if an MCP server or authorization server redirected a request to another origin, that origin received custom request headers (such as an X-API-Key set in requestInit.headers) and the mcp-session-id header. On a 307 or 308 redirect it also received the request body, including OAuth token requests with their refresh_token and client_secret. On current runtimes fetch already drops the Authorization header across origins, so that header was not the leak.

Why it matters. This is the client-side counterpart to the first two: the server you connect to is not trusted input only for what it says, but for where it sends you. A malicious or compromised MCP server, or a compromised authorization server, can bounce a request to a host it controls and collect whatever custom headers your harness attached. Combined with the issuer issue from last week, it shows OAuth clients for MCP are a rich target.

Who is affected. Applications using StreamableHTTPClientTransport, SSEClientTransport or the SDK's OAuth client functions such as auth(). Stdio clients are not affected. Affected: @modelcontextprotocol/sdk through 1.31.0 and @modelcontextprotocol/client 2.0.0–2.2.0.

Fix. Upgrade to sdk 1.32.0 or client 2.3.0. Redirects are now followed only within the same origin, and not at all in browsers. If your MCP server or authorization server redirects to another origin on purpose, configure the final URL instead. Setting redirectPolicy: 'follow' on a transport restores the old behaviour and the exposure, so avoid it. Without an upgrade, pass a fetch that refuses redirects: (url, init) => fetch(url, { ...init, redirect: 'error' }).

What this means if you run AI coding agents

Most people reading this are not writing MCP servers, but their agents talk to them, and many internal tools and agent harnesses embed this SDK. The advisories do not name which off-the-shelf agents ship an affected version, so check the tools you build, and watch vendor release notes for the ones you only use.

1. Find your version. In each project: npm ls @modelcontextprotocol/sdk, and for 2.x npm ls @modelcontextprotocol/server @modelcontextprotocol/client @modelcontextprotocol/express.
2. Upgrade to sdk 1.32.0, or server/client 2.3.0 with express 2.0.2 and server-legacy 2.3.1 where you use them.
3. Set maxToolInputElements on every HTTP McpServer, and set a request body limit.
4. Set expectedResource if your authorization server serves several services, and return the audience from verifyAccessToken().
5. Search for taskStore. If you use it, upgrade or drop it, and plan to move off experimental tasks.
6. Check redirects. If a redirect may have reached a host you do not control, rotate API keys and client_secret values the client held and revoke its tokens.
7. Look in logs for out-of-memory restarts of MCP server processes, isError results after you set the limit (a sign it is working, or too tight), unexpected 401s after enabling the audience check, and requests from your client to hosts you do not recognise.

None of this needs new tooling: it is npm, grep and configuration. The recurring theme is that secure behaviour was added as an option rather than a default, so a version bump by itself is a false comfort.

What Beam can and cannot do here

Beam cannot see inside your own MCP server or client code, and it will not flag these CVEs. What it does is review what an agent is about to connect to: beam scan .mcp.json --mcp checks an MCP config for risky patterns and version pinning without launching the servers, which helps you spot unfamiliar remote servers before an agent connects. The scan is heuristic and cannot judge a server's runtime behaviour or its dependency tree. If the point is to see what an agent did after a tool call, Beam's agent hooks and local event log cover that, but they are not a memory limiter or an OAuth audience check. For the review process, see MCP security: review servers before connecting your agent and the practical MCP guide. Everything Beam records stays on your device, as described in how Beam stays local.

Why upgrade-plus-config advisories are easy to miss

Security fixes that ship disabled are a recurring pattern in libraries that cannot change defaults without breaking existing users. Dependency scanners will report "patched" once you pass 1.32.0, and a green dashboard does not mean maxToolInputElements or expectedResource is set. Add the two options to your service templates and code review checklist, and write a small test for each: a call with more than the limit should return isError, and a token with the wrong audience should return 401.

The same boundary shows up elsewhere in the MCP ecosystem. Remote servers are untrusted input on an authentication path, as in agentjacking via an MCP server and Cursor MCP config poisoning. The October incident posts on npm packages that hijack MCP and LLM traffic and the Langflow MCP stdio remote code execution flaw show other ways a connected component can reach code or credentials.

Frequently asked questions

Which MCP TypeScript SDK versions fix these four advisories?

@modelcontextprotocol/sdk 1.32.0 fixes all four on the 1.x line. On 2.x, @modelcontextprotocol/server 2.3.0 and @modelcontextprotocol/client 2.3.0 fix the server and client issues, @modelcontextprotocol/express needs 2.0.2 and @modelcontextprotocol/server-legacy needs 2.3.1.

Is upgrading enough to be protected?

Not for two of them. The memory fix adds a maxToolInputElements option that is off by default, and the audience fix adds an expectedResource setting that is also off by default. You must turn both on, and lower your request size limit, after upgrading.

Are stdio MCP servers and clients affected?

No for the memory exhaustion advisory (stdio-only servers are not affected) and for the redirect advisory (stdio clients are not affected). The task-isolation and bearer-audience issues concern HTTP servers.

How do I know if the experimental tasks bug applies to me?

It applies only if your HTTP server passes taskStore to McpServer or Server. The advisory suggests running grep -ri taskstore --exclude-dir=node_modules . and, if nothing is found, you are not affected. The 2.x packages are not affected.

Do I need to rotate credentials?

Only if a redirect may have reached a host you do not control. In that case the advisory says to rotate the API keys and client_secret your application held and revoke its tokens.

Can Beam detect these vulnerabilities?

No. Beam scans skill and MCP config files with heuristics and a version-pin check, but it does not read the dependency tree of your own MCP server or client code. Use npm ls to check versions.

Related reading

• MCP TypeScript SDK OAuth flaw CVE-2026-104850
• MCP security: review servers before connecting your agent
• MCP security practical guide
• Agentjacking through an MCP server
• Advisories: GHSA-46jr-4wx8-v453, GHSA-22jm-h49p-29qw, GHSA-rvq5-wwqv-78pq, GHSA-6prh-2h8m-c8cw and the SDK repository

Versions and advisory details were checked against the GitHub advisories on October 20, 2026. Check the advisories for later changes.