MCP TypeScript SDK: One HTTP request within the default size limit could exhaust server memory during validation.
Does it affect you?
Timeline
15 Oct- Published by GitHub advisory15 Oct
- Seen by Patchwire23 Oct
- Fix released15 Oct
Versions of @modelcontextprotocol/sdk
Versions of @modelcontextprotocol/server
Related alerts(6)
Same packages- 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 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 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