modelcontextprotocol-sdk

### Summary 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. ### Am I affected? Yes, if clients you do not fully trust can reach your server over Streamable HTTP. A body parser such as `express.json()` does not protect you, because it does not limit batch length. Servers that only use stdio

### Summary 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. ### Am I affected? Only if your HTTP server passes `taskStore` to `McpServer` or `Server`. If `grep -ri taskstore --exclude-dir=node_modules .` finds nothing, you are not affected. Affected versions: `@modelcontextprotocol/sdk` 1.

CVE: CVE-2026-111767

### Summary 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. ### Am I affected? Yes, if clients you do not fully trust can reach your server over HTTP. The risk is highest for `McpServer` tools whose input contains an array or a record. stdio-only servers are not affected. Affected versions:

CVE: CVE-2026-111768

### Summary 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` already drops the `Authorization` header across origins. ### Am I affected? Yes, if your application us

CVE: CVE-2026-111769

### Summary 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. ### Am I affected? Yes, if your HTTP server uses `requireBearerAuth()` or `verifyBearerToken()`, its authorization server also issues tokens for other services, and your `verifyAccessToken()` does not check the token's audience (`aud`) itself. Affected versions: - `@modelcontextprotocol/sdk` 1.6.0 throu

CVE: CVE-2026-111771

### Summary 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 provider ### Am I affected? Yes, if both of these hold: - your application uses the SDK's OAuth client ov

CVE: CVE-2026-104850

### Summary 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. ### Impact This advisory covers two related but distinct vulnerabilities. A deployment may be affected by one or both. #### Issue 1: Transport re-use **What happens:** When a single `StreamableHTTPServerTransport` instance handles multiple client requests, JSON-RPC message ID collisions cause responses to be routed to

CVE: CVE-2026-25536

### Impact 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% CPU utilization, server hang/crash, and

CVE: CVE-2026-0621

The Model Context Protocol (MCP) TypeScript SDK does not enable DNS rebinding protection by default for HTTP-based servers. When an HTTP-based MCP server is run on localhost without authentication with `StreamableHTTPServerTransport` or `SSEServerTransport` and has not enabled `enableDnsRebindingProtection`, a malicious website could exploit DNS rebinding to bypass same-origin policy restrictions and send requests to the local MCP server. This could allow an attacker to invoke tools or access resources exposed by the MCP server on behalf of the user in those limited circumstances. Note that r

CVE: CVE-2025-66414