• Uses @modelcontextprotocol/sdk 1.3.0 through 1.31.0, or @modelcontextprotocol/server 2.0.0 through 2.2.0 (or a patched version without maxToolInputElements set).
• MCP server is exposed over an HTTP transport (not stdio-only).
• Clients that are not fully trusted can reach the server over HTTP without being authenticated before requests reach the SDK.

Affected

@modelcontextprotocol/sdk >=1.3.0 <1.32.0 · @modelcontextprotocol/server >=2.0.0 <2.3.0

Fixed in

1.32.0 · 2.3.0

ID

GHSA-46jr-4wx8-v453

• Uses @modelcontextprotocol/server version 2.0.0 through 2.2.0.
• MCP server is reached over HTTP (not stdio).
• More than one client can reach the HTTP endpoint.
• Code creates the transport or the McpServer/Server instance once at startup and shares it across clients, instead of once per request or per session.

Affected

@modelcontextprotocol/server >=2.0.0 <2.3.0

Fixed in

2.3.0

ID

GHSA-jm63-cq47-j5jp

• Uses @modelcontextprotocol/sdk 1.10.0 through 1.30.0, or @modelcontextprotocol/server 2.0.0, @modelcontextprotocol/node 2.0.0, or @modelcontextprotocol/hono 2.0.0.
• MCP server is exposed over Streamable HTTP (not stdio-only).
• Clients that are not fully trusted can reach the server's HTTP endpoint.
• Requests are not authenticated by the application before reaching the SDK.

Affected

@modelcontextprotocol/sdk >=1.10.0 <1.30.1 · @modelcontextprotocol/server >=2.0.0 <2.1.0 · @modelcontextprotocol/node >=2.0.0 <2.1.0 · @modelcontextprotocol/hono >=2.0.0 <2.0.1

Fixed in

1.30.1 · 2.1.0 · 2.0.1

ID

GHSA-f897-62hf-6gxq

Source summary

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.24.0 through 1.31.0. T

Affected

@modelcontextprotocol/sdk >=1.24.0 <1.32.0

Fixed in

1.32.0

ID

GHSA-22jm-h49p-29qw

Source summary

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 uses StreamableHTTPClientTran

Affected

@modelcontextprotocol/sdk <1.32.0 · @modelcontextprotocol/client >=2.0.0 <2.3.0

Fixed in

1.32.0 · 2.3.0

ID

GHSA-6prh-2h8m-c8cw

Source summary

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 over HTTP, through a

Affected

@modelcontextprotocol/sdk >=1.12.0 <1.31.0 · @modelcontextprotocol/client >=2.0.0 <2.2.0

Fixed in

1.31.0 · 2.2.0

ID

GHSA-6qxp-vccf-f47h