2vulnerabilities
- Critical0 (0.0%)
- High1 (50.0%)
- Medium0 (0.0%)
- Moderate1 (50.0%)
- Low0 (0.0%)
modelcontextprotocol-client
Ecosystem: npm
Downloads:
- 0CriticalAffects 0 versions
- 1HighAffects 1 version
- 0MediumAffects 0 versions
- 1ModerateAffects 1 version
- 0LowAffects 0 versions
Monthly breakdown
- 2 vulnerabilities
- Critical: 0
- High: 1
- Medium: 0
- Moderate: 1
- Low: 0
Vulnerabilities (2)
Known vulnerabilities affecting modelcontextprotocol-client, based on data from OSV.
| ID | Severity | Summary | Affected versions | Published | Source |
|---|---|---|---|---|---|
| GHSA-6prh-2h8m-c8cw | Moderate | MCP TypeScript client SDK: HTTP client transports and OAuth requests followed cross-origin redirects and re-sent custom headers and request bodies### 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 us |
| GitHub (opens in a new tab) | |
| GHSA-6qxp-vccf-f47h | High | MCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP server### 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 ov |
| GitHub (opens in a new tab) |
- GHSA-6prh-2h8m-c8cwModerateMCP TypeScript client SDK: HTTP client transports and OAuth requests followed cross-origin redirects and re-sent custom headers and request bodies
>= 2.0.0, < 2.3.0
### 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 us
CVE: CVE-2026-111769
- GHSA-6qxp-vccf-f47hHighMCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP server
>= 2.0.0, < 2.2.0
### 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 ov
CVE: CVE-2026-104850