MCP TypeScript SDK CVE-2026-104850

Exploitation requires ALL of: (1) the application uses the SDK's OAuth client over HTTP via an authProvider on a transport, the withOAuth() middleware, or direct auth()/fetchToken() calls; (2) it holds credentials for a legitimate authorization server (a stored refresh_token/client_secret, or a bundled provider's client_secret/signed assertion); and (3) it connects to an MCP server the operator does not fully trust. For @modelcontextprotocol/client 2.x the window is narrower - only bundled providers (ClientCredentialsProvider, PrivateKeyJwtProvider, StaticPrivateKeyJwtProvider, CrossAppAccessProvider) constructed WITHOUT expectedIssuer, credentials stored/supplied WITHOUT issuer, direct fetchToken() calls, or custom providers reading storage back through OAuthTokensSchema/OAuthClientInformationSchema. Limiting factors that reduce real-world exposure: stdio clients are NOT affected, MCP servers built with the SDK are NOT affected, and the trigger depends on the victim choosing to connect to an untrusted server rather than a purely attacker-initiated reach. Note residual risk even after upgrade: a fresh interactive sign-in, and credentials persisted without an issuer before upgrading, still go to whichever authorization server the MCP server names until issuer is added or the credentials are cleared; skipIssuerMetadataValidation:true on 2.x also defeats the fix.

This is a credential-disclosure flaw (CWE-345, Insufficient Verification of Data Authenticity) in the MCP TypeScript SDK's OAuth client, rated CVSS 7.5 with vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N - pure confidentiality impact, no integrity or availability loss, which directly contradicts the single input Tag 'Denial Of Service'. No EPSS score was provided, so exploitation-probability cannot be quantified from this data. The CVE is NOT in CISA KEV and no public exploit code is referenced, so this is no public exploit identified at time of analysis - not active exploitation. The network vector and lack of required interaction make the mechanism trivial once triggered, but real-world risk is gated by a meaningful precondition the CVSS vector understates: the victim client must already hold valid OAuth credentials AND voluntarily connect to an MCP server the operator does not fully trust. This is therefore a genuine priority for the specific population of applications using the SDK's HTTP OAuth client against semi-trusted servers (where leaked refresh_tokens, client_secrets, or signed assertions enable downstream impersonation against the legitimate authorization server), but closer to a moderate, conditional risk than a mass-exploitable internet-facing bug for the general population. Key missing signals: no EPSS, no KEV confirmation, no POC evidence - absence noted explicitly, not treated as safety.

An attacker stands up (or compromises) an MCP server and lures a victim application - one using the SDK's OAuth client over HTTP while holding credentials for a legitimate authorization server - into connecting to it. With no user interaction, the attacker's server advertises its own authorization server and the SDK sends the stored refresh_token and client_secret (or a bundled provider's client_secret/signed assertion) to the attacker-controlled endpoint, which the attacker then replays against the real authorization server. No public exploit code is referenced, but the network vector and low attack complexity make the credential-theft step straightforward once a connection is established.