MCP SDK vulnerabilities: seven fixes from October 2026 and the code changes your own MCP server needs

Between 30 September and 15 October 2026, the maintainers of the official MCP SDK for TypeScript published seven security advisories, five of them rated high, and for four of them updating the package may not be enough. If your company runs its own MCP server over HTTP that lets an AI assistant reach internal data, you are affected by the MCP SDK vulnerability in which the server could deliver one client's response to another. The fix in version 2.3.0 of @modelcontextprotocol/server also requires a code change. Local servers that run over stdio are not affected by the server-side issues.

For the wider question of what a company should automate at all, see our guide to AI automation of business processes. Webhooks, access rights and API keys in automation workflows are covered in our article on automation security. This piece deals with one specific library and what to do about it this week. If you want an MCP server or an AI integration reviewed by people who build them, see our business process automation service.

Who the MCP SDK vulnerability affects and who it does not

Any project that uses the MCP SDK for TypeScript with a server or client talking over HTTP is affected; servers that only run locally over stdio are not affected by the server-side issues.

MCP (Model Context Protocol) is a protocol that connects an AI application to tools and data. The server offers tools, such as looking up an order, and the client is the application with the AI model that calls them. The MCP specification, version 2026-07-28, defines two standard transports. With stdio, the client application launches the server as a subprocess on the same computer. With Streamable HTTP, the server runs as a separate service with a single address and receives every message as an HTTP request, so more than one client can connect to it.

For a company, this leads to three situations:

• your own MCP server reachable over HTTP, for example deployed on a server or in the cloud so that several people can access internal data: the issues with shared instances, token validation and request size apply to it,
• your own application or script that uses the SDK to connect to MCP servers over HTTP and signs in with OAuth or an API key: the two client-side issues apply, where credentials could end up at a third-party address,
• a server that only runs locally over stdio, for example from a desktop AI application: the server-side issues do not apply, and you can update during routine maintenance.

You can find the version in package.json or by running npm ls in the project folder. The 1.x line is a single package, @modelcontextprotocol/sdk. The 2.x line is split into separate packages, @modelcontextprotocol/server, @modelcontextprotocol/client, and adapters for Express, Node and Hono. If the output shows no @modelcontextprotocol package, these advisories do not concern your project. If it does, continue with the table below.

Seven MCP SDK advisories in one table

Five advisories concern the server and two the client; version 1.32.0 of @modelcontextprotocol/sdk fixes every issue in the 1.x line.

All seven are published in the security advisories of the MCP TypeScript SDK repository on GitHub. Each one lists the affected versions, the patched versions and whether you also need to change your code.

What could happen	Side	Severity (CVSS)	Patched version	Is updating enough?
A shared server instance delivered one client's response to another	server 2.x	high, 7.7	server 2.3.0	no, code change needed
The server accepted a token issued for another service	server	medium, 6.8	sdk 1.32.0, server 2.3.0, express 2.0.2	no, the audience check must be turned on
One request within the 4 MiB limit exhausted server memory	server	high, 7.5	sdk 1.32.0, server 2.3.0	no, limits must be set
No limit on request size or batch length	server	high, 7.5	sdk 1.30.1, server and node 2.1.0, hono 2.0.1	yes
Experimental tasks were not tied to the session that created them	server 1.x	high, 8.6	sdk 1.32.0	yes, or remove taskStore
The OAuth client sent credentials to an authorization server chosen by the MCP server	client	high, 7.5	sdk 1.31.0, client 2.2.0	not always, depends on configuration and stored tokens
On a redirect to another origin the client re-sent headers and the request body	client	medium, 6.5	sdk 1.32.0, client 2.3.0	yes, rotate keys if in doubt

As of 22 October 2026, the newest versions on npm are 1.32.1 for @modelcontextprotocol/sdk and 2.3.1 for both server and client. None of the seven advisories reports that anyone has exploited the flaws. For the two server memory issues, however, the advisories state that an attacker needs no credentials unless the server authenticates requests before they reach the SDK. While you postpone the update, a single request from anyone who can reach the server's address can bring it down.

Where updating is not enough: four code changes

For shared server instances, token validation, input limits and the OAuth client, a developer has to change code or configuration after the update.

One server for all clients

Advisory GHSA-jm63-cq47-j5jp describes code that creates the transport or the server once at startup and routes every HTTP request through it. The SDK matched messages to a connection by the JSON-RPC id alone. SDK clients number their requests from 0, so these ids collide in normal use, and a response carrying one user's data could reach another. Until the fix, the README examples of the Hono, Express, Fastify and Node adapters showed exactly this pattern. Check first any server that a person or an AI tool wrote from those examples.

Version 2.3.0 refuses to be shared: a second connection fails with ALREADY_CONNECTED and a stateless transport rejects its second request. After the update alone, such a server stops answering. The code has to create a new server for every request, or one server and one transport per session. The 1.x line has had the same type of flaw fixed since version 1.26.0 of 4 February 2026.

A token issued for another service

When one authorization server issues tokens for several services, an MCP server using requireBearerAuth() or verifyBearerToken() also accepted a valid token meant for another service. The MCP security best practices state that a server must not accept a token that was not issued for it. The patched versions add an expectedResource setting that is off by default. You have to turn it on and also return the token's audience from verifyAccessToken(). With only the first change, the server rejects every request with a 401. On older versions, a verifyAccessToken() that rejects any token whose aud does not include your server closes the gap.

A limit on input size

One request within the default 4 MiB limit could exhaust memory during input validation, and the process aborted with JavaScript heap out of memory. According to advisory GHSA-46jr-4wx8-v453, the risk is highest for tools whose input contains an array or a record. The new maxToolInputElements option is off by default, so set it just above the largest input your tools need and lower maxRequestBodySize as well. If you parse the request body yourself, for example with express.json(), set the limit there too.

The OAuth client and old stored tokens

A client built on the SDK could send its refresh_token and client_secret to an authorization server chosen by the MCP server. The fix stores the issuer with the credentials, but tokens saved before the update do not have it. Add it to them, or delete them so that users sign in again. Bundled providers such as ClientCredentialsProvider need an expectedIssuer. If the client may have connected to a server you do not trust, the advisory recommends rotating the client secret or signing key and revoking the issued tokens.

For token validation and input limits, without these changes your package.json shows the patched version while the server behaves exactly as it did before the update.

What a company should do: six steps for this week

Find out who maintains the server, check the versions, update a test copy, change the code, test the server with two clients at once and rotate keys if in doubt.

1. List every MCP server and client in the company and the person who maintains each one. Include prototypes that someone built with an AI tool and left running.
2. Run npm ls in every project and look for @modelcontextprotocol packages. In the 1.x line the target is at least 1.32.0, in the 2.x line server and client at least 2.3.0 and the adapters as listed in the table.
3. Update a test copy first, not the live server. A server with a shared instance stops answering after the update until the code is changed.
4. Make the changes from the previous section: a server per request or per session, the audience check, maxToolInputElements and maxRequestBodySize, and the issuer for OAuth. If the code uses the experimental taskStore, remove it, because the 2026-07-28 specification replaced it with a new extension.
5. Test the server with two clients at the same time and check that each one receives only its own responses. Also send a request larger than 4 MiB and check that the server rejects it with a 413 and keeps running.
6. If the client may have connected to a server outside your control, or a redirect may have sent it there, rotate the API keys and client secret and revoke the issued tokens.

We described a similar situation with the access change in the Supabase Data API: an application works until the library or service beneath it changes, and then everything depends on whether someone in the company can adjust it. A server without an owner stays on the old version with every flaw that applies to it.

The MCP SDK vulnerability in practice: who owns the server

In our view, the biggest risk is an MCP server that started as a quick experiment and has nobody to update it.

With automations in smaller companies, we see workflows that began as an experiment and kept running. MCP servers carry the same risk with a wider reach, because the server gives an AI assistant access to orders, invoices or customer data. If the server handles personal data, a response delivered to the wrong client means that data reached another user. Checking who the data belongs to is the server's job. How the model then works with the data it receives is explained in our article what an LLM is and what AI cannot do.

Before building your own server, ask whether you need one. If all you need is to connect two common tools, an automation platform kept up to date by its operator may be enough. You will find a comparison in our article on automation for small businesses with n8n and Make.

How we handle it at Denva: we connect integrations through the tools' official interfaces and keep access to the necessary minimum. We set up critical steps so that a failure alerts you straight away, and we hand over the solution documented, so you understand it and are not tied to us.

When you can handle it yourself and when to bring us in

You can handle it yourself if:

• the server is maintained by the developer who wrote it and knows its code,
• you only use local stdio servers in a desktop AI application,
• the update passed on a test copy and the server answers two clients at once correctly.

It is worth bringing us in if:

• the server was built by an AI tool or an outside supplier and nobody in the company knows its code,
• the server works with orders, invoices or customers' personal data,
• the client signs in with OAuth and it is unclear which tokens and keys need rotating.

Conclusion

If none of your projects contains an @modelcontextprotocol package, there is nothing to do. Update a local stdio server during your next maintenance window. If an MCP server runs over HTTP and handles company or personal data, the update and the four code changes belong in this week, first on a test copy and then with a two-client test. Have someone take over a server without an owner, or switch it off until that happens.

FAQ

Frequently asked questions.

Does the MCP SDK vulnerability affect local stdio servers?

Not the server-side issues. The advisories on shared instances, memory exhaustion and missing request limits state that stdio-only servers are not affected, and neither client-side issue affects stdio clients. We still recommend updating to a patched version during your next maintenance window.

Which MCP SDK version should I update to?

In the 1.x line, at least @modelcontextprotocol/sdk 1.32.0; in the 2.x line, server and client 2.3.0 or later. As of 22 October 2026 the newest versions on npm are 1.32.1 and 2.3.1. The express, node and hono adapters have their own patched versions: 2.0.2, 2.1.0 and 2.0.1.

Has anyone exploited these flaws?

The advisories do not report any exploitation. For the two server memory issues, however, they state that an attacker needs no credentials unless the server authenticates requests before they reach the SDK, so do not postpone the update.

Why did my MCP server stop responding after the update?

Most likely it shares one server or transport instance between several clients. Version 2.3.0 of @modelcontextprotocol/server rejects that with an ALREADY_CONNECTED error, so the code has to create a server for every request or for every session.

Do I need to rotate API keys after these fixes?

Only if the client may have connected to an MCP server you do not trust, or a redirect may have sent it to a third-party address. In that case the advisories recommend rotating API keys, the client secret or signing key and revoking the issued tokens.