The Official SDK Needed Four Fixes at Once: Session Confusion, Audience Blindness, Redirect Leaks and Memory Exhaustion in the MCP TypeScript Stack

2026-10-26 AI Vulnerabilities & CVEs by al-ice.ai Editorial

On 20 October 2026 the maintainers of the official Model Context Protocol TypeScript SDK published four advisories at once, all fixed in @modelcontextprotocol/sdk 1.32.0 (with @modelcontextprotocol/server 2.3.0, express 2.0.2 and server-legacy 2.3.1 carrying the server-side half). Taken individually each is a medium-to-high SDK bug. Taken together they read as a single audit of the SDK’s trust boundaries — session, audience, origin, and input size — and every one of the four boundaries was open. The batch matters beyond MCP developers because the SDK ships inside toolchains that do not look like MCP projects: both Angular CLI LTS branches (21.2.x and 20.3.x) pin the vulnerable @modelcontextprotocol/sdk@1.31.0 exactly, per a dependency report filed against the Angular repository the same day.

The four, in severity order

CVE-2026-111767 (GHSA-22jm-h49p-29qw, 8.6 High): experimental tasks were not tied to the session that created them. The experimental taskStore never checked which session created a task, so clients sharing one InMemoryTaskStore could list, read, and cancel each other’s tasks — cross-client data leak plus cross-client interference, unauthenticated, over the network (CVSS:3.1 AV:N/AC:L/PR:N/UI:N, CWE-639 and CWE-862). Affected: 1.24.0 through before 1.32.0. The advisory adds a deprecation with teeth: experimental tasks were superseded by a redesigned extension in the 2026-07-28 specification, and the recommended action is to stop using them, not just to upgrade past them. This is the direct sequel to the cross-client leak we covered in March (CVE-2026-25536) — same store, same confusion, higher score.

CVE-2026-111768 (GHSA-46jr-4wx8-v453, 7.5 High): one HTTP request within the default size limit could exhaust server memory during validation. Servers placed no limit on how many array elements and object keys they validated in a single request, so one request inside the default 4 MiB body limit could drive the process into JavaScript heap-out-of-memory and abort it — no credentials needed unless authentication sits in front of the SDK (CWE-770). Affected: the server package 2.0.0 through before 2.3.0 (SDK range reported as 1.3.0 through before 1.32.0). Pair this with the MCP-Go unbounded-body denial of service we covered this month: two independent MCP stacks, same missing control — bounding what one request may ask the server to chew on.

CVE-2026-111771 (GHSA-rvq5-wwqv-78pq, 6.8 Medium): server bearer authentication accepted tokens issued for another service. The SDK’s server-side bearer authentication had no way to check token audience, so where one authorization server issues tokens for several services, a valid token for service B was accepted by your MCP server A (CWE-863, AC:H/PR:L tempering an otherwise C:H/I:H impact). Affected: 1.6.0 through before 1.32.0. The fix is the audience check in requireBearerAuth() / verifyBearerToken() / verifyAccessToken() — the exact control Claude Duet’s credential-isolation architecture exists to enforce at the product layer. The SDK now enforces at the library layer what the flagship agent product enforces at the deployment layer; both teams independently concluded that a bearer token without a bound audience is a confused deputy waiting for a second service.

CVE-2026-111769 (GHSA-6prh-2h8m-c8cw, 6.5 Medium): HTTP client transports and OAuth requests followed cross-origin redirects and re-sent credentials. Redirect to any origin and that origin received custom request headers — an X-API-Key from requestInit.headers, the mcp-session-id header — and on 307/308 the request body too, including OAuth token requests carrying refresh_token and client_secret. Current runtimes’ fetch already drops Authorization across origins; the SDK re-sent everything else (CWE-200). Affected: everything before 1.32.0. The attack shape is a malicious MCP or authorization server answering with a redirect — the server you chose vouches for the server you never chose. Anyone who read the OpenCode MCP-OAuth RCE from last week will recognise the family: OAuth-adjacent flows where the client trusts one party and pays another.

Why a batch is worse than four singles

Four advisories landing the same day in the reference implementation is a supply-chain event, not four application bugs. The SDK is the code most MCP servers and clients are actually running, and the Angular CLI pin shows how far the blast radius extends past projects that think of themselves as MCP software — a frontend toolchain carrying an agent-protocol SDK carrying four trust-boundary flaws. The remediation is correspondingly mechanical and correspondingly easy to defer: upgrade to 1.32.0 / 2.3.0 / 2.0.2 / 2.3.1, stop using experimental tasks entirely, and turn on the audience check rather than assuming your authorization server’s tokens are single-purpose. Fleet-upgrade issues filed within days of publication show scanners already flagging the batch across unrelated repositories; the gap between “scanner knows” and “maintainer upgraded” is now the exposure window, and it is measured in weeks.

Our verification was read-only. The advisory titles, CVE/GHSA identifiers, affected and fixed versions, CVSS scores and vectors, CWE assignments, fix PR references, and remediation versions above were read first-hand from the four GitLab Advisory Database mirrors of the official GitHub Security Advisories (all dated 20 October 2026), with the same-day Angular CLI dependency report read first-hand as field corroboration of the batch and the downstream pin. We did not install any SDK version, run any MCP server or client, replay any redirect, mint any token, or send any validation payload. NVD entries are linked from the advisories and were not independently re-scraped. Brave Search was used for discovery only.

Sources: