Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 are not affected. Affected versions: - `@modelcontextprotocol/sdk` 1.10.0 through 1.30.0 - `@modelcontextprotocol/server` 2.0.0 - `@modelcontextprotocol/node` 2.0.0 - `@modelcontextprotocol/hono` 2.0.0 Fix Upgrade to: - 1.x: `@modelcontextprotocol/sdk` 1.30.1 or later - 2.x: `@modelcontextprotocol/server` 2.1.0, `@modelcontextprotocol/node` 2.1.0 and `@modelcontextprotocol/hono` 2.0.1 or…
Recommended action: Upgrade to 1.30.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: - @modelcontextprotocol/sdk 1.3.0 through 1.31.0 - @modelcontextprotocol/server 2.0.0 through 2.2.0 Fix Upgrade to: - 1.x: @modelcontextprotocol/sdk 1.32.0 or later - 2.x: @modelcontextprotocol/server 2.3.0 or later Upgrading alone changes nothing. The patched versions add an McpServer option, maxToolInputElements, that is off by default. Make both of these changes: 1. Set maxToolInputElements just above the…
Recommended action: Upgrade to 1.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 through 1.31.0 - @modelcontextprotocol/server 2.0.0 through 2.2.0 - @modelcontextprotocol/express 2.0.0 through 2.0.1 - @modelcontextprotocol/server-legacy 2.0.0 through 2.3.0 Fix Upgrade to: - 1.x: @modelcontextprotocol/sdk 1.32.0 or later - 2.x: @modelcontextprotocol/server 2.3.0 or later, together with @modelcontextprotocol/express 2.0.2 or later if you use it - @modelcontextprotocol/server-legacy 2.3.1 or later…
Recommended action: Upgrade to 1.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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=nodemodules . finds nothing, you are not affected. Affected versions: @modelcontextprotocol/sdk 1.24.0 through 1.31.0. The 2.x packages are not affected. Fix Upgrade to @modelcontextprotocol/sdk 1.32.0 or later. Each task is now tied to the session that created it, so a client that starts a new session can no longer reach its earlier tasks. If you cannot upgrade yet, remove taskStore, or create one InMemoryTaskStore per session.
Recommended action: Upgrade to 1.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 refreshtoken and clientsecret. On current runtimes fetch already drops the Authorization header across origins. Am I affected? Yes, if your application uses StreamableHTTPClientTransport, SSEClientTransport, or the SDK's OAuth client functions such as auth(). stdio clients are not affected. Affected versions: - @modelcontextprotocol/sdk all versions through 1.31.0 - @modelcontextprotocol/client 2.0.0 through 2.2.0 Fix Upgrade to: - 1.x: @modelcontextprotocol/sdk 1.32.0 or later - 2.x: @modelcontextprotocol/client 2.3.0 or later Redirects are now followed only within the same…
Recommended action: Upgrade to 1.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 refreshtoken and clientsecret stored from an earlier sign-in - the clientsecret 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 over HTTP, through any of: - an authProvider on a transport - the withOAuth() middleware - direct calls to auth() or fetchToken() - it may connect to an MCP server you do not fully trust while holding credentials for a legitimate authorization server Affected versions: - @modelcontextprotocol/sdk 1.12.0 through 1.30.1 - @modelcontextprotocol/client 2.0.0 through 2.1.0, only for: - bundled providers without…
Recommended action: Upgrade to 1.31.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 the wrong client's HTTP connection. 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. The second client's request overwrites the first client's mapping entry, routing the response to the wrong HTTP stream. What is affected: All request types — tools/call, resources/read, prompts/get,…
Recommended action: Upgrade to 1.26.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 denial of service for all clients. Affected Versions All versions of @modelcontextprotocol/sdk prior to the patched release. Patches v1.25.2 contains b392f02ffcf37c088dbd114fedf25026ec3913d3 the fix modifies the regex pattern to prevent backtracking. Workarounds - Avoid using exploded patterns ({/id}, {?tags}) in resource templates - Implement request timeouts and rate limiting - Validate URIs before processing to reject…
Recommended action: Upgrade to 1.25.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 running HTTP-based MCP servers locally without authentication is not recommended per MCP security best practices. This issue does not affect servers using stdio transport. Servers created via createMcpExpressApp() now have this protection enabled by default when binding to localhost. Users with custom Express configurations are advised to update to version 1.24.0 and apply the exported…
Recommended action: Upgrade to 1.24.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.