Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 refreshtoken and clientsecret. On current runtimes fetch already drops the Authorization header across origins. Am I affected? Yes, if your application uses StreamableHTTPClientTransport, SSEClientTransport, or the SDK's OAuth client functions such as auth(). stdio clients are not affected. Affected versions: - @modelcontextprotocol/sdk all versions through 1.31.0 - @modelcontextprotocol/client 2.0.0 through 2.2.0 Fix Upgrade to: - 1.x: @modelcontextprotocol/sdk 1.32.0 or later - 2.x: @modelcontextprotocol/client 2.3.0 or later Redirects are now followed only within the same…
Recommended action: Upgrade to 2.3.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 refreshtoken and clientsecret stored from an earlier sign-in - the clientsecret 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 any of: - an authProvider on a transport - the withOAuth() middleware - direct calls to auth() or fetchToken() - it may connect to an MCP server you do not fully trust while holding credentials for a legitimate authorization server Affected versions: - @modelcontextprotocol/sdk 1.12.0 through 1.30.1 - @modelcontextprotocol/client 2.0.0 through 2.1.0, only for: - bundled providers without…
Recommended action: Upgrade to 2.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.