CVE-2026-104850

CVE-2026-104850 is a high-severity security vulnerability in @modelcontextprotocol/sdk (npm), affecting versions >= 1.12.0, < 1.31.0. It is fixed in 1.31.0, 2.2.0.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

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

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

Impact

CVE-2026-104850 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.31.0, 2.2.0); upgrading removes the vulnerable code path.

Affected versions

@modelcontextprotocol/sdk (>= 1.12.0, < 1.31.0) @modelcontextprotocol/client (>= 2.0.0, < 2.2.0)

Security releases

@modelcontextprotocol/sdk → 1.31.0 (npm) @modelcontextprotocol/client → 2.2.0 (npm)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

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.

Frequently Asked Questions

  1. What is CVE-2026-104850? CVE-2026-104850 is a high-severity security vulnerability in @modelcontextprotocol/sdk (npm), affecting versions >= 1.12.0, < 1.31.0. It is fixed in 1.31.0, 2.2.0.
  2. How severe is CVE-2026-104850? CVE-2026-104850 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which packages are affected by CVE-2026-104850?
    • @modelcontextprotocol/sdk (npm) (versions >= 1.12.0, < 1.31.0)
    • @modelcontextprotocol/client (npm) (versions >= 2.0.0, < 2.2.0)
  4. Is there a fix for CVE-2026-104850? Yes. CVE-2026-104850 is fixed in 1.31.0, 2.2.0. Upgrade to this version or later.
  5. Is CVE-2026-104850 exploitable, and should I be worried? Whether CVE-2026-104850 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-104850 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-104850?
    • Upgrade @modelcontextprotocol/sdk to 1.31.0 or later
    • Upgrade @modelcontextprotocol/client to 2.2.0 or later

Other vulnerabilities in @modelcontextprotocol/sdk

CVE-IDSeverityPackage summary
GHSA-F897-62HF-6GXQHigh@modelcontextprotocol/sdk: MCP TypeScript SDK: HTTP server transports and handlers did not limit request body size or JSON-RPC batch lengthCVE-2026-111768High@modelcontextprotocol/sdk: MCP TypeScript SDK: One HTTP request within the default size limit could exhaust server memory during validationCVE-2026-111771Medium@modelcontextprotocol/sdk: MCP TypeScript SDK: Server bearer authentication accepted tokens issued for another serviceCVE-2026-111767High@modelcontextprotocol/sdk: MCP TypeScript SDK: Experimental tasks were not tied to the session that created themCVE-2026-111769Medium@modelcontextprotocol/sdk: MCP TypeScript client SDK: HTTP client transports and OAuth requests followed cross-origin redirects and re-sent custom headers and request…

Stop the waste.
Protect your environment with Kodem.

Get a personalized demo
Get a personalized demo