4vulnerabilities
- Critical0 (0.0%)
- High3 (75.0%)
- Medium0 (0.0%)
- Moderate1 (25.0%)
- Low0 (0.0%)
modelcontextprotocol-server
Ecosystem: npm
Downloads:
- 0CriticalAffects 0 versions
- 3HighAffects 3 versions
- 0MediumAffects 0 versions
- 1ModerateAffects 1 version
- 0LowAffects 0 versions
Monthly breakdown
- 4 vulnerabilities
- Critical: 0
- High: 3
- Medium: 0
- Moderate: 1
- Low: 0
Vulnerabilities (4)
Known vulnerabilities affecting modelcontextprotocol-server, based on data from OSV.
| ID | Severity | Summary | Affected versions | Published | Source |
|---|---|---|---|---|---|
| GHSA-f897-62hf-6gxq | High | MCP TypeScript SDK: HTTP server transports and handlers did not limit request body size or JSON-RPC batch length### Summary 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 |
| GitHub (opens in a new tab) | |
| GHSA-46jr-4wx8-v453 | High | MCP TypeScript SDK: One HTTP request within the default size limit could exhaust server memory during validation### Summary 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: |
| GitHub (opens in a new tab) | |
| GHSA-jm63-cq47-j5jp | High | MCP TypeScript server SDK: Shared transport or server instances delivered one HTTP client's messages to another### Summary 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 |
| GitHub (opens in a new tab) | |
| GHSA-rvq5-wwqv-78pq | Moderate | MCP TypeScript SDK: Server bearer authentication accepted tokens issued for another service### 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 throu |
| GitHub (opens in a new tab) |
- GHSA-f897-62hf-6gxqHighMCP TypeScript SDK: HTTP server transports and handlers did not limit request body size or JSON-RPC batch length
>= 2.0.0, < 2.1.0
### Summary 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
- GHSA-46jr-4wx8-v453HighMCP TypeScript SDK: One HTTP request within the default size limit could exhaust server memory during validation
>= 2.0.0, < 2.3.0
### Summary 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:
CVE: CVE-2026-111768
- GHSA-jm63-cq47-j5jpHighMCP TypeScript server SDK: Shared transport or server instances delivered one HTTP client's messages to another
>= 2.0.0, < 2.3.0
### Summary 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
CVE: CVE-2026-111770
- GHSA-rvq5-wwqv-78pqModerateMCP TypeScript SDK: Server bearer authentication accepted tokens issued for another service
>= 2.0.0, < 2.3.0
### 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 throu
CVE: CVE-2026-111771