GHSA-6qxp-vccf-f47h: High severity npm/@modelcontextprotocol/client vulnerability
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 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 expectedIssuer - credentials stored or supplied without issuer - direct calls to fetchToken() - providers that read storage back through OAuthTokensSchema or OAuthClientInformationSchema
Not affected:
- MCP servers built with the SDK - stdio clients
Fix Upgrade to:
- 1.x: @modelcontextprotocol/sdk 1.31.0 or later - 2.x: @modelcontextprotocol/client 2.2.0 or later, and @modelcontextprotocol/core 2.2.0 or later if you import it directly
The client now records the authorization server as issuer on saved credentials and does not send them to a different one. The user signs in again, or the call throws.
In the following cases, upgrading to the patched version is not enough. You also need to make a change:
- Bundled providers (ClientCredentialsProvider, PrivateKeyJwtProvider, StaticPrivateKeyJwtProvider, CrossAppAccessProvider): pass expectedIssuer, for example expectedIssuer: 'https://auth.example.com'. Without it they still use whichever authorization server the MCP server names. - Credentials saved without issuer: tokens and client information your OAuthClientProvider persisted (file, keychain, database) before upgrading, including everything 1.x saved before 1.31.0. They still go to whichever authorization server is named at first use. Add issuer to them, or clear them so users sign in again. - Your own OAuthClientProvider: save exactly what saveTokens() and saveClientInformation() are given, including issuer. For pre-registered credentials, include issuer in what clientInformation() returns.
Not covered by this fix:
- a new interactive sign-in, which still goes to the authorization server the MCP server names. Only complete sign-ins for servers you trust. - refreshAuthorization() and exchangeAuthorization() called directly - 2.x with skipIssuerMetadataValidation: true
If an affected client may have connected to an untrusted MCP server, rotate its client secret or signing key and revoke its tokens.
If you cannot upgrade yet, connect OAuth clients only to MCP servers you trust. 2.0.0 and 2.1.0 already accept expectedIssuer.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@modelcontextprotocol/clientto a version that resolves this vulnerability.Fixed in 2.2.0 - Upgrade
Upgrade
npm/@modelcontextprotocol/sdkto a version that resolves this vulnerability.Fixed in 1.31.0 - Upgrade
Upgrade
@modelcontextprotocol/sdkto a version that resolves this vulnerability.Fixed in 1.31.0 - Upgrade
Upgrade
@modelcontextprotocol/clientto a version that resolves this vulnerability.Fixed in 2.2.0 - Upgrade
Upgrade
@modelcontextprotocol/coreto a version that resolves this vulnerability.Fixed in 2.2.0 - Configuration
Pass expectedIssuer to each bundled provider.
Bundled OAuth providers (ClientCredentialsProvider, PrivateKeyJwtProvider, StaticPrivateKeyJwtProvider, CrossAppAccessProvider) expectedIssuer = the expected authorization-server issuer, for example https://auth.example.com - Configuration
For custom providers, save exactly what saveTokens() and saveClientInformation() receive, including issuer; for pre-registered credentials, include issuer in the value returned by clientInformation().
OAuthClientProvider issuer = included - Compensating control
If you cannot upgrade yet, connect OAuth clients only to MCP servers you trust.
- Operational
For credentials persisted without issuer, add issuer or clear the stored tokens and client information so users sign in again.
- Operational
If an affected client may have connected to an untrusted MCP server, rotate its client secret or signing key and revoke its tokens.
Event History
Frequently Asked Questions
Which applications are exposed?
Applications are exposed if they use the SDK OAuth client over HTTP through an authProvider on a transport, withOAuth() middleware, or direct auth() or fetchToken() calls, and may connect to an MCP server they do not fully trust while holding credentials for a legitimate authorization server.
What does an attacker need to exploit this?
An attacker needs control of, or the ability to compromise, an MCP server the client connects to. That server can specify an attacker-controlled authorization server, causing the client to send stored or configured OAuth credentials without user interaction.
What credentials could be disclosed?
The client may disclose a refresh_token and client_secret retained from an earlier sign-in. It may also disclose a client_secret or signed assertion configured on a bundled provider.
Are all affected @modelcontextprotocol/client configurations impacted?
No. Version 2.0.0 through 2.1.0 is affected only for bundled providers without expectedIssuer, credentials stored or supplied without issuer, direct fetchToken() calls, or providers that read storage through OAuthTokensSchema or OAuthClientInformationSchema.