• 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/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 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 - @model

Affected

@modelcontextprotocol/sdk >=1.6.0 <1.32.0 · @modelcontextprotocol/server >=2.0.0 <2.3.0 · @modelcontextprotocol/express >=2.0.0 <2.0.2 · @modelcontextprotocol/server-legacy >=2.0.0 <2.3.1

Fixed in

1.32.0 · 2.3.0 · 2.0.2 · 2.3.1

ID

GHSA-rvq5-wwqv-78pq

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