On this page
MCP TypeScript SDK Vulnerabilities: Are You Affected? (Nov 2026)

Upgrade to @modelcontextprotocol/sdk 1.32.0 or later, or to 2.3.0 or later of the 2.x packages. If you only use MCP servers that your AI client starts over stdio, most of these bugs never reach you. If you run an MCP server over HTTP, or build a client that signs in with OAuth, check the table below: four of the fixes do nothing until you also change your code.

The official TypeScript SDK sits under most Node-based MCP servers. In the week of 31 October to 6 November 2026, npm counted about 88 million downloads of @modelcontextprotocol/sdk and 26 million of the 2.x @modelcontextprotocol/server package. So when the SDK has a bug, a lot of servers have it too.

What happened and when

The SDK maintainers published seven security advisories on the typescript-sdk advisories page between 30 September and 15 October 2026. The GitHub Advisory Database picked them up on 6, 20 and 27 October, and NVD published four of them as CVEs on 5 November. That last step is why scanners and npm audit started flagging them this month, weeks after the fixes shipped.

The fixes came out together: @modelcontextprotocol/sdk 1.32.0 and the 2.x packages 2.3.0, both on 2 October 2026, with small follow-ups on 5 October (1.32.1, 2.3.1). Current versions on 8 November 2026 are 1.32.2 and 2.4.0.

We covered three of these in the October MCP security roundup. This page has all seven and what to do about each.

The seven advisories

Advisory Severity What goes wrong Who's hit Fixed in Upgrade alone fixes it?
CVE-2026-111768 High (7.5) One request under the 4 MiB limit can run the server out of memory. No login needed HTTP servers, sdk 1.3.0-1.31.0, server 2.0.0-2.2.0 sdk 1.32.0, server 2.3.0 No: set maxToolInputElements and a body limit
GHSA-f897-62hf-6gxq (no CVE) High (7.5) No limit on POST body size or JSON-RPC batch length HTTP servers, sdk 1.10.0-1.30.0, server/node/hono 2.0.0 sdk 1.30.1, server and node 2.1.0, hono 2.0.1 Yes
CVE-2026-111770 High (7.7) One HTTP client gets another client's responses HTTP servers on server 2.0.0-2.2.0 that share one server or transport server 2.3.0 No: one server per request or session
CVE-2026-111767 High (8.6) Clients can list, read and cancel each other's experimental tasks HTTP servers passing taskStore, sdk 1.24.0-1.31.0 sdk 1.32.0 Yes
CVE-2026-104850 High (7.5) A malicious MCP server can collect your stored refresh_token and client_secret OAuth clients, sdk 1.12.0-1.30.1, client 2.0.0-2.1.0 sdk 1.31.0, client 2.2.0 Not always: stored credentials and bundled providers need changes
CVE-2026-111771 Medium (6.8) Server accepts a token issued for a different service HTTP servers using requireBearerAuth(), sdk 1.6.0-1.31.0, server 2.0.0-2.2.0 sdk 1.32.0, server 2.3.0 No: turn on expectedResource
CVE-2026-111769 Medium (6.5) Client follows a redirect to another site and re-sends API-key headers, the session id, and OAuth token request bodies HTTP and OAuth clients, all sdk through 1.31.0, client 2.0.0-2.2.0 sdk 1.32.0, client 2.3.0 Yes

Severity scores are the CVSS 3.1 scores on each advisory. The full advisories also cover the smaller packages (@modelcontextprotocol/express, server-legacy, hono, node). If you have any of those installed, upgrade them to the latest version as well.

Am I affected?

It depends on how you use MCP, not just on the version number.

You... What applies What to do
Use MCP servers in Claude, Cursor or VS Code, all over stdio (the usual npx ... config) None of the seven: the server bugs need an HTTP endpoint, and the client bugs need an HTTP or OAuth connection Make sure your servers aren't running an old cached copy (next section). That's it
Run a server over HTTP (--transport http, --port, a Docker image, a hosted endpoint) CVE-2026-111768, GHSA-f897, CVE-2026-111770, CVE-2026-111767, CVE-2026-111771 Upgrade the server. If you built it, also make the code changes below
Build an app or agent that connects to MCP servers over HTTP with the SDK's client CVE-2026-104850, CVE-2026-111769 Upgrade, then check your stored OAuth credentials
Use a proxy like mcp-remote to reach a remote server The client bugs, inside the proxy Update the proxy; mcp-remote 0.16.5 is on the fixed 2.x packages

The advisories are clear that stdio-only servers aren't affected by the server-side bugs. The most common setup is still worth a 2-minute check, because an old SDK copy can sit in your npx cache and run the day you switch a server to HTTP.

How to check which SDK version you have

In your own project:

npm ls @modelcontextprotocol/sdk @modelcontextprotocol/server @modelcontextprotocol/client

You want sdk at 1.32.0 or later and the 2.x packages at 2.3.0 or later.

For servers launched with npx: npx installs each server into a cache folder and can keep using that copy. A server installed in September can still be running a September SDK. When we ran the check below on our own test machine, the cache still held SDK 1.29.0 and 2.0.0, both affected.

macOS, Linux, or Git Bash on Windows:

find "$(npm config get cache)/_npx" \
  -path "*/node_modules/@modelcontextprotocol/*/package.json" \
  -not -path "*/node_modules/@modelcontextprotocol/*/node_modules/*" \
  -exec grep -m1 -H '"version"' {} \;

Windows PowerShell:

$c = npm.cmd config get cache
Get-ChildItem "$c\_npx" -Recurse -Filter package.json -ErrorAction SilentlyContinue |
  Where-Object { $_.Directory.Parent.Name -eq '@modelcontextprotocol' } |
  ForEach-Object { '{0}  {1}' -f (Get-Content $_.FullName -Raw | ConvertFrom-Json).version, $_.Directory.FullName }

(npm.cmd rather than npm, because PowerShell's default script policy blocks npm.ps1 on many machines.)

To clear old copies, close your AI client and delete the _npx folder inside the npm cache folder that the first command prints. npx reinstalls each server on its next launch with the latest SDK its version range allows. This removes nothing but cached installs.

For a Docker image: pull the latest tag. An image built before 2 October 2026 can't contain the fixed SDK, because it didn't exist yet.

Where the servers we list stand

We checked the latest npm release of every listed server that installs with npx on 8 November 2026. Most declare the SDK with a ^ range, so a fresh install pulls 1.32.2. Two pin an older version:

Server Latest release SDK it ships Status
Brave Search 2.1.4 (17 Sep) sdk 1.30.0, pinned Affected in HTTP mode (CVE-2026-111768, GHSA-f897). HTTP is opt-in and binds to 127.0.0.1 by default, but its README says the HTTP endpoint is unauthenticated. The bump to 1.32.2 is on main (26 Oct) but not released yet, and main doesn't set maxToolInputElements yet, which CVE-2026-111768 also needs. Stay on stdio. We lowered its grade from B to C on 8 November
Shopify Dev MCP 1.18.0 sdk 1.29.0, pinned stdio only, so the server-side bugs don't apply
Playwright MCP 0.0.84 sdk 1.32.0, bundled in playwright-core Fixed. Matters if you use --port
Filesystem 2.2.0 server ^2.3.1 Fixed
Context7 4.5.1 server 2.3.1 Fixed
Firecrawl 3.38.0 server 2.3.1 Fixed
Chrome DevTools MCP 1.12.0 server/client 2.3.1 Fixed
Postman 2.15.0 sdk ^1.32.0 Fixed
DBHub, MongoDB 1.6.0, 3.2.2 2.x with ^ ranges Fresh install gets 2.4.0
PayPal, Perplexity, DataForSEO and other ^1.x servers various sdk ^1.x Fresh install gets 1.32.2; check your npx cache

The version is only half the story. CVE-2026-111770, CVE-2026-111771 and CVE-2026-111768 need code changes in the server itself, which we can't see from a package listing. For an HTTP server you didn't build, check its changelog for these CVE numbers, or ask the maintainer.

If you build an MCP server

Upgrade first. Then make these changes, all taken from the advisories:

Memory exhaustion (CVE-2026-111768). The fix adds an option that's off by default. Set it just above the largest input your tools need, and lower the request size limit:

const server = new McpServer(info, { maxToolInputElements: 10_000 });
// and set maxRequestBodySize on the transport or createMcpHandler().
// If you parse the body yourself (express.json(), Fastify), set that parser's limit too.

A call over the element limit gets an isError: true result instead of crashing the process.

Messages going to the wrong client (CVE-2026-111770). Don't create the server or transport once at startup and share it. Build a new McpServer and transport per request, keep one per session (set sessionIdGenerator), or pass createMcpHandler() a factory that returns a new server on every call. Until this release, the README examples for the hono, express, fastify and node packages showed the shared pattern, so check code you copied from them. After the upgrade, shared instances fail loudly: a second connect() throws ALREADY_CONNECTED.

Tokens for other services (CVE-2026-111771). Make both changes together:

requireBearerAuth({ verifier, expectedResource: new URL('https://mcp.example.com/mcp') });
// and return the token's audience from verifyAccessToken() as AuthInfo.resource (a URL)

With only the first change, every request gets a 401. On any version, you can instead reject tokens whose aud doesn't include your server inside verifyAccessToken(). More on audience checks in MCP server authentication.

Experimental tasks (CVE-2026-111767). If grep -ri taskstore --exclude-dir=node_modules . finds nothing, you're not affected. If it finds something, stop using them: the 2026-07-28 spec replaced experimental tasks with a redesigned extension.

The general rules for a safe server are in how to create an MCP server securely. If your server only needs to serve one person on one machine, stdio avoids this whole class of bug; see local MCP server.

If you build an MCP client

Stolen OAuth credentials (CVE-2026-104850). Before 1.31.0, the MCP server decided which authorization server got your client's stored refresh_token and client_secret. Upgrading helps for new sign-ins, but not for:

  • credentials your OAuthClientProvider saved before the upgrade. They have no issuer, so clear them or add it.
  • the bundled providers (ClientCredentialsProvider, PrivateKeyJwtProvider, StaticPrivateKeyJwtProvider, CrossAppAccessProvider). Pass expectedIssuer.
  • your own OAuthClientProvider. It must save exactly what saveTokens() and saveClientInformation() receive, including issuer.

Cross-origin redirects (CVE-2026-111769). After the upgrade, redirects are followed only within the same origin. Don't set redirectPolicy: 'follow': that brings the bug back. If a server redirects to another origin on purpose, configure the final URL.

If your client may have talked to a server you don't trust while on an affected version, both advisories give the same advice: rotate the client secret, signing key and API keys it held, and revoke its tokens.

What to do in 5 steps

1. Find your SDK versions

Run npm ls in your own projects and the npx-cache command above. Anything below sdk 1.32.0 or below 2.3.0 on the 2.x packages needs an update.

2. Clear the npx cache and update Docker images

Delete the _npx cache folder and pull fresh images, so servers relaunch on the fixed SDK.

3. Keep HTTP servers off until they're fixed

Run servers over stdio where you can. For an HTTP server on an affected SDK, bind it to 127.0.0.1 and put a token in front of it until the vendor ships a fix. Brave Search 2.1.4 is the one in our directory still waiting.

4. Make the code changes if you built a server

Set maxToolInputElements and a body limit, stop sharing server instances, turn on expectedResource, and drop taskStore.

5. Re-check OAuth clients and rotate if in doubt

Add issuer to stored credentials or clear them, set expectedIssuer on bundled providers, and rotate secrets if the client ever connected to a server you don't control.

Other MCP SDKs

The TypeScript SDK wasn't alone. In October the Python SDK fixed the same kinds of bug (unbounded request bodies, tokens for other services, cross-origin redirects), and the Java, Kotlin and Rust SDKs each had one. The details and fixed versions are in the October roundup. Go's community mcp-go library also got a CVE this month: CVE-2026-123272, fixed in v1.2.1, where a malicious server could get tokens for other resources through its OAuth metadata.

We scan for new MCP advisories every night. To vet a server yourself, see are MCP servers safe? and the security best practices. If you run MCP servers for a team and want a second pair of eyes on the setup, get in touch.

Frequently asked questions

Is the MCP TypeScript SDK safe to use?

Yes, on current versions. @modelcontextprotocol/sdk 1.32.0 and the 2.x packages at 2.3.0 fix all seven advisories, provided you also make the four code changes described above where they apply. On 8 November 2026 the latest versions were 1.32.2 and 2.4.0.

What version of the MCP TypeScript SDK fixes the CVEs?

@modelcontextprotocol/sdk 1.32.0 for 1.x. For 2.x: server and client 2.3.0, express 2.0.2, server-legacy 2.3.1, node 2.1.0 and hono 2.0.1.

Am I affected if I only use MCP servers in Claude or Cursor?

Mostly no. The server-side bugs need an HTTP endpoint, and servers your client starts with npx use stdio. Still, clear your npx cache so servers run on a current SDK, and don't switch a server to HTTP mode on an old version.

Why is npm audit flagging these now if the fixes came out in October?

NVD published four of the advisories as CVEs on 5 November 2026, and many scanners read from NVD. The fixes shipped on 2 October.

Does upgrading the SDK fix everything?

No. CVE-2026-111768 and CVE-2026-111771 add settings that are off by default, CVE-2026-111770 needs one server per request or session, and CVE-2026-104850 leaves credentials stored before the upgrade unprotected. Each needs a change in your code.

Which MCP servers in your directory are still affected?

On 8 November 2026, Brave Search 2.1.4 ships SDK 1.30.0 and is affected when run in its opt-in HTTP mode. The SDK bump is on its main branch but not released, so we lowered its grade from B to C. Every other listed npx server we checked is on a fixed SDK or gets one on a fresh install.

Does this affect the Python SDK?

These seven advisories are TypeScript only. The Python SDK had five similar ones in October, fixed in mcp 1.30.0 and 2.2.0; see the October roundup.