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
4 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 2.1.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, an MCP server reached over HTTP could deliver one client's responses and notifications to another client. This happened when clients shared one stateless transport, or one McpServer or Server instance. Messages were matched to a connection by JSON-RPC id alone. SDK clients number requests from 0, so ids collide in normal use. Am I affected? Yes, if more than one client can reach your HTTP endpoint and your code creates the transport or the server once at startup, instead of once per request or per session. Until this release, the README examples of @modelcontextprotocol/hono, express, fastify and node showed that pattern. Affected versions: @modelcontextprotocol/server 2.0.0 through 2.2.0. Not affected: - createMcpHandler() with a factory that builds a new server on every call - stdio servers - @modelcontextprotocol/sdk 1.26.0 and later Fix Upgrade to @modelcontextprotocol/server 2.3.0 or later. You also need to change your code. The SDK now refuses to…
Recommended action: Upgrade to 2.3.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, 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 2.3.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 2.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.