Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦
📦 npm
Not in CISA KEV
HIGH severity

MCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP serverGHSA-6qxp-vccf-f47h

HIGHFix: modelcontextprotocol/typescript-sdk#2887

GHSA-6qxp-vccf-f47h is a high-severity (CVSS 7.5) CWE-345 vulnerability in @modelcontextprotocol/sdk. A fix is available for @modelcontextprotocol/sdk — see the affected versions and patch details below.

Also known asCVE-2026-104850
Published
Updated
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Oct 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-6qxp-vccf-f47h.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs7th percentile — riskier than 7% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-6qxp-vccf-f47h by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

2 pkgs affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

77Kother npm packages depend on this — each one inherits the vulnerability until it's patched upstream
@modelcontextprotocol/sdknpm
39.4Mdownloads / week
@modelcontextprotocol/clientnpm
4.7Mdownloads / week

Description

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.

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
📦npm@modelcontextprotocol/sdk≥ 1.12.0&&< 1.31.01.31.0npm install @modelcontextprotocol/sdk@1.31.0
📦npm@modelcontextprotocol/client≥ 2.0.0&&< 2.2.02.2.0npm install @modelcontextprotocol/client@2.2.0

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @modelcontextprotocol/sdk, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update @modelcontextprotocol/sdk to 1.31.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6qxp-vccf-f47h is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

Red HatImportant

Red Hat rates this vulnerability as an Important severity because it allows a malicious endpoint to silently extract sensitive authentication secrets and tokens over the network without requiring user interaction. The exposure specifically affects environments where Model Context Protocol client components establish…

Workaround published by Red Hat
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability.
Source: Red Hat security advisory for GHSA-6qxp-vccf-f47h (CC BY 4.0)

Frequently Asked Questions

### 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
O3 Security · Impact-Aware SCA

Is GHSA-6qxp-vccf-f47h in your dependencies?

Find it across npm, including transitive dependencies.

Scan my dependencies How O3 SCA works
MCP TypeScript SDK: OAuth client could send credentials…