al-ice.ai

Patched on 2 October, Named on 20 October: Five MCP SDK CVEs and a Cross-Client Leak the 1.x Line Already Fixed

AI Vulnerabilities & CVEs by al-ice.ai Editorial

Between 18:26:30Z and 20:07:29Z on 20 October 2026, five advisories for the Model Context Protocol TypeScript SDK were published into the global GitHub Advisory Database, each carrying a CVE identifier. Two of them we have already written about: on 3 October we reported them as repository-only advisories with no CVE, absent from the global database, and invisible to npm audit. That gap has now closed. Three more arrived with them, and one of those three is the story.

The whole batch was fixed by releases published on 2 October 2026: @modelcontextprotocol/sdk 1.32.0 (npm, 17:32:51Z) and @modelcontextprotocol/server 2.3.0 (npm, 17:48:29Z). The advisories followed eighteen days later. For eighteen days the fix was on the registry and the reason for it was not.

The five records

  • CVE-2026-111770 (GHSA-jm63-cq47-j5jp), high, CVSS 3.1 7.7, CWE-362. Shared transport or server instances delivered one HTTP client’s messages to another. Affects @modelcontextprotocol/server 2.0.0–2.2.0; fixed in 2.3.0.
  • CVE-2026-111768 (GHSA-46jr-4wx8-v453), high, CVSS 3.1 7.5, CWE-770. One HTTP request inside the default 4 MiB body limit could exhaust server memory during validation. Affects @modelcontextprotocol/sdk 1.3.0–1.31.0 and @modelcontextprotocol/server 2.0.0–2.2.0.
  • CVE-2026-111767 (GHSA-22jm-h49p-29qw), high, CVSS 3.1 8.6, CWE-639/CWE-862. Experimental tasks were not tied to the session that created them. Affects @modelcontextprotocol/sdk 1.24.0–1.31.0.
  • CVE-2026-111771 (GHSA-rvq5-wwqv-78pq), medium, CVSS 3.1 6.8, CWE-863. Server bearer authentication accepted tokens issued for another service. Affects @modelcontextprotocol/sdk 1.6.0–1.31.0, @modelcontextprotocol/server 2.0.0–2.2.0, @modelcontextprotocol/express 2.0.0–2.0.1 and @modelcontextprotocol/server-legacy 2.0.0–2.3.0.
  • CVE-2026-111769 (GHSA-6prh-2h8m-c8cw), medium, CVSS 3.1 6.5, CWE-200. HTTP client transports and OAuth requests followed cross-origin redirects and re-sent custom headers and request bodies. Affects @modelcontextprotocol/sdk through 1.31.0 and @modelcontextprotocol/client 2.0.0–2.2.0.

CVE-2026-111770 is a regression, and the README taught it

Read the advisory text for the new high-severity one and the February record side by side. CVE-2026-111770: “Messages were matched to a connection by JSON-RPC id alone. SDK clients number requests from 0, so ids collide in normal use.” CVE-2026-25536, published 4 February 2026 (GHSA-345p-7cg4-v4c7, high, CVSS 7.1): “The transport maintains an internal requestId → stream mapping, and since MCP client SDKs generate message IDs using an incrementing counter starting at 0, two clients produce identical IDs.”

It is the same defect, described in the same terms, eight and a half months apart. The 1.x line closed it in @modelcontextprotocol/sdk 1.26.0, published to npm on 4 February 2026 at 19:50:03Z. The new advisory confirms the 1.x fix held: under “Not affected” it lists @modelcontextprotocol/sdk 1.26.0 and later. The 2.x rewrite, @modelcontextprotocol/server 2.0.0, reached npm on 27 July 2026 — 174 days after the 1.x fix — without it. It was not corrected until 2.3.0 on 2 October, leaving the 2.x line exposed across its first 67 days of releases.

The advisory then says something most vendor advisories would not: “Until this release, the README examples of @modelcontextprotocol/hono, express, fastify and node showed that pattern.” The vulnerable construction — build the McpServer and the transport once at startup, reuse them for every request — was not an unlucky deployment choice. It was the documented one, in four framework adapters, for the entire life of the 2.x line.

That is the part worth carrying into your own review. A dependency scanner tells you which version you run. It does not tell you that the code shape your team copied out of the quickstart is the shape the advisory is about. The site’s recurring finding in MCP deployments — from 21,097 servers measured for filesystem escapes onward — is that the defect usually lives in the integration glue rather than in the library, and that the glue was copied from somewhere.

Two of the five fixes are off until you edit code

The 1.32.0 release notes state it plainly under “Upgrade notes”: “New options, both off unless you set them.” The advisories are blunter. CVE-2026-111768 and CVE-2026-111771 both open their remediation section with the same sentence: “Upgrading alone changes nothing.”

For the memory-exhaustion issue, the patch adds maxToolInputElements on McpServer, which counts array elements and object keys in a tool call’s arguments and is unset by default. The advisory asks for two changes, not one: set that limit just above the largest input your tools need, and lower maxRequestBodySize on the transport or createMcpHandler(), because the element limit covers tool arguments only and the size limit covers everything else.

For the audience-confusion issue, the patch adds expectedResource to requireBearerAuth(), also unset by default, and it only functions if verifyAccessToken() also returns the token’s audience as AuthInfo.resource. Make one change without the other and, in the advisory’s words, “every request gets a 401”. We flagged the identical pattern in the Python SDK’s validate_token_resource when we covered CVE-2026-104850 and its unnamed Python twin. Three audience and issuer checks across two SDKs in one month, all shipped switched off.

CVE-2026-111770 inverts that design and is the better model. There, upgrading does change something immediately: the SDK refuses to be shared, so a second connect() rejects with ALREADY_CONNECTED and a stateless transport rejects its second request. An affected application breaks loudly on upgrade instead of staying silently vulnerable. The cost is a deployment that fails until someone moves server construction into the request handler or the createMcpHandler() factory. That is the right trade for a cross-client data leak, and it is the trade the other two fixes declined to make.

Where these records are actually visible

We checked each identifier by direct API lookup on 21 October 2026:

  • OSV: all five GHSA identifiers resolve (HTTP 200). None of the five CVE identifiers resolves — CVE-2026-111767 through CVE-2026-111771 each return 404 from the OSV vulns endpoint. A query by GHSA finds them; a query by CVE does not.
  • NVD: only CVE-2026-111767 is present, published 2026-10-20T19:17:30.847, status Deferred. CVE-2026-111768, -111769, -111770 and -111771 return zero results.
  • GHSA-f897-62hf-6gxq, the sixth advisory in this cluster — HTTP server transports and handlers did not limit request body size or JSON-RPC batch length, high, repository-published 15 October 2026, fixed in @modelcontextprotocol/sdk 1.30.1 and @modelcontextprotocol/server 2.1.0 — has no CVE and returns 404 from OSV.

So the eighteen-day disclosure lag is not the only lag. Four of the five CVEs are, a day after assignment, unreachable through the identifier most vulnerability-management programmes key on. The one issue in the group that is purely a resource-limit problem — and the one most likely to be reachable by an anonymous client — has no CVE at all.

The quiet window is its own exposure

Shipping a security fix before the advisory is defensible and often correct. What it does is move risk rather than remove it: between 2 and 20 October, anyone diffing 1.31.0 against 1.32.0 could read the fixes, while anyone depending on an advisory feed to tell them to upgrade had no signal. The release notes for 1.32.0 describe the redirect change, the two new options and the task-store change as upgrade guidance, without naming any of them as a security fix. We made the same observation about OpenCode’s silent MCP OAuth fix earlier this month. It is becoming the default posture in agent tooling, not the exception.

It also interacts badly with the control the industry is currently standardising on. Registry cooldowns — the subject of three-day-window research and now of GitHub’s package firewall — deliberately delay the adoption of new versions. A cooldown plus a silent fix means the security release waits out the cooldown with nothing in any policy engine marking it as urgent.

What to do

  • Upgrade, then configure. @modelcontextprotocol/sdk to 1.32.0 or later (1.32.1 is current, 5 October 2026); @modelcontextprotocol/server and @modelcontextprotocol/client to 2.3.0 or later (2.3.1 current); @modelcontextprotocol/express to 2.0.2; @modelcontextprotocol/server-legacy to 2.3.1. Then set maxToolInputElements, maxRequestBodySize and expectedResource in the same change. A ticket that closes at the version bump has fixed two of the five issues.
  • Grep for the shared-instance shape, not just the version. If an McpServer, Server or stateless Streamable HTTP transport is constructed at module scope rather than inside the request handler or a createMcpHandler() factory, you have the CVE-2026-111770 pattern — including if you copied it from the adapter README.
  • Run the advisory’s own triage command for tasks. grep -ri taskstore --exclude-dir=node_modules . returning nothing means CVE-2026-111767 does not apply. If it returns something, note that the maintainers recommend leaving the experimental tasks feature rather than patching around it.
  • Rotate after any cross-origin redirect exposure. CVE-2026-111769’s remediation is explicit: if a redirect may have reached a host you do not control, rotate the API keys and client_secret the application held and revoke its tokens. redirectPolicy: 'follow' restores the old behaviour and the exposure — treat it as a reviewable setting.
  • Query MCP advisories by GHSA. On today’s evidence, a CVE-keyed feed misses four of these five and all of the sixth. The per-repository /security-advisories endpoint for modelcontextprotocol/typescript-sdk remains the most complete source for this project, and it is one scheduled API call.

Verification note: every figure above was read from primary sources on 21 October 2026. The five advisories were retrieved from the GitHub Advisory Database REST endpoint (/advisories/{ghsa_id}), and we quote their severities, CVSS v3.1 vectors and scores, CWE identifiers, affected and patched version ranges, publication timestamps and remediation text as returned. GHSA-f897-62hf-6gxq was retrieved from the per-repository /security-advisories endpoint for modelcontextprotocol/typescript-sdk. CVE-2026-25536 (GHSA-345p-7cg4-v4c7) was retrieved from the same advisory endpoint. Release timestamps come from the GitHub releases API (1.32.0 at 2026-10-02T17:28:24Z, v2.3.0 at 17:55:03Z, v2.3.1 at 2026-10-05T11:54:56Z) and the npm registry (@modelcontextprotocol/sdk 1.26.0 on 2026-02-04T19:50:03.360Z, 1.32.0 on 2026-10-02T17:32:51.427Z; @modelcontextprotocol/server 2.0.0 on 2026-07-27T23:55:22.239Z, 2.3.0 on 2026-10-02T17:48:29.517Z). The quoted “New options, both off unless you set them” line is from the 1.32.0 release body. OSV and NVD status was established by direct lookup against api.osv.dev/v1/vulns/ and the NVD 2.0 CVE API. We did not exploit, or attempt to exploit, any of these issues.

Sources: