In affected versions, MCP servers reachable over HTTP put no limit on the size of a POST body or on the number of messages in a JSON-RPC batch. Large requests could exhaust the server's memory, and one long batch could block it from serving anyone else. No credentials were needed, unless your application authenticates requests before they reach the SDK.
In affected versions, the SDK's server-side bearer authentication had no way to check that a token was issued for your server (its audience). Where one authorization server issues tokens for several services, a valid token for another service was also accepted by your MCP server.
In affected versions, servers put no limit on how many array elements and object keys they validated in one request. One HTTP request within the default 4 MiB size limit could exhaust the server's memory, and the process aborted with JavaScript heap out of memory. No credentials are needed, unless you authenticate requests before they reach the SDK.
In affected versions, the experimental tasks feature (taskStore) did not check which session created a task. Clients sharing one InMemoryTaskStore could list, read and cancel each other's tasks. Experimental tasks are deprecated. The 2026-07-28 specification replaced them with a redesigned extension. The best course of action is to stop using them.
In affected versions, the SDK's HTTP client transports and OAuth requests followed redirects to any origin. 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 it also received the request body, including OAuth token requests with their refresh_token and client_secret. On current runtimes fetch …
In affected versions, the SDK's OAuth client let the MCP server decide which authorization server received the client's OAuth credentials. Credentials were not tied to the authorization server they belong to. A malicious or compromised MCP server could name its own authorization server. With no user interaction, the client would send it: the refresh_token and client_secret stored from an earlier sign-in the client_secret or signed assertion configured on a bundled …
Cross-client data leak via two distinct issues: (1) reusing a single StreamableHTTPServerTransport across multiple client requests, and (2) reusing a single McpServer/Server instance across multiple transports. Both are most common in stateless deployments.
A ReDoS vulnerability in the UriTemplate class allows attackers to cause denial of service. The partToRegExp() function generates a regex pattern with nested quantifiers (([^/]+(?:,[^/]+))) for exploded template variables (e.g., {/id}, {?tags*}), causing catastrophic backtracking on malicious input. Who is affected: MCP servers that register resource templates with exploded array patterns and accept requests from untrusted clients. Attack result: An attacker sends a crafted URI via resources/read request, causing 100% …