Skip to content

fix(deps): update dependency @modelcontextprotocol/sdk to v1.31.0 [security] - #154

Merged
khepri-bot[bot] merged 1 commit into
mainfrom
renovate/security-updates
Oct 16, 2026
Merged

fix(deps): update dependency @modelcontextprotocol/sdk to v1.31.0 [security]#154
khepri-bot[bot] merged 1 commit into
mainfrom
renovate/security-updates

Conversation

@khepri-bot

@khepri-bot khepri-bot Bot commented Oct 6, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
@modelcontextprotocol/sdk (source) 1.30.0 → 1.31.0 age confidence

MCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP server

CVE-2026-104850 / GHSA-6qxp-vccf-f47h

More information

Details

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 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.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

MCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP server

CVE-2026-104850 / GHSA-6qxp-vccf-f47h

More information

Details

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 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.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Release Notes

modelcontextprotocol/typescript-sdk (@​modelcontextprotocol/sdk)

v1.31.0

Compare Source

Upgrade notes

  • Stored OAuth tokens and client information now include an issuer field. Storage that rejects unknown fields needs to allow it.
  • Pass expectedIssuer when constructing ClientCredentialsProvider, PrivateKeyJwtProvider or StaticPrivateKeyJwtProvider. Constructing them without it is deprecated.

What's Changed

Full Changelog: modelcontextprotocol/typescript-sdk@1.30.1...1.31.0

v1.30.1

Compare Source

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/typescript-sdk@1.30.0...1.30.1

Configuration

📅 Schedule: (in timezone America/New_York)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

@khepri-bot
khepri-bot Bot requested a review from a team October 6, 2026 22:44
@khepri-bot khepri-bot Bot added the renovate label Oct 6, 2026
@khepri-bot
khepri-bot Bot enabled auto-merge (squash) October 6, 2026 22:44
@khepri-bot
khepri-bot Bot force-pushed the renovate/security-updates branch from ee79c18 to 2f84d5e Compare October 16, 2026 16:48
@khepri-bot
khepri-bot Bot merged commit f57f715 into main Oct 16, 2026
1 check passed
@khepri-bot
khepri-bot Bot deleted the renovate/security-updates branch October 16, 2026 21:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

renovate

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants