CVE-2026-104850: 
JavaScript vulnerability analysis and mitigation

CVE-2026-104850 is an OAuth credential hijacking vulnerability in the MCP TypeScript SDK (Model Context Protocol) that allows a malicious or compromised MCP server to redirect a client's OAuth credentials to an attacker-controlled authorization server without any user interaction. The vulnerability affects @modelcontextprotocol/sdk versions 1.12.0 through 1.30.1 and @modelcontextprotocol/client versions 2.0.0 through 2.1.0. It was published to the GitHub Advisory Database on October 6, 2026, with a CVSS v3.1 base score of 7.5 (High) (Github Advisory).

The root cause is a failure to bind stored OAuth credentials to the specific authorization server they were issued for, classified as CWE-345 (Insufficient Verification of Data Authenticity) and CWE-522 (Insufficiently Protected Credentials). When an MCP client connects to an MCP server over HTTP, the server's protected resource metadata can name any authorization server it chooses; the SDK did not validate that this server matched the one the stored credentials belong to. As a result, the client would automatically forward refresh_token, client_secret, or signed JWT assertions to the attacker-named server — covering bundled providers (ClientCredentialsProvider, PrivateKeyJwtProvider, StaticPrivateKeyJwtProvider, CrossAppAccessProvider) and any custom OAuthClientProvider that uses auth() or fetchToken(). The fix introduces an issuer stamp on saved credentials and an expectedIssuer parameter on bundled providers, enforced via the new AuthorizationServerMismatchError (Github Advisory, PR #2887).

Successful exploitation results in full confidentiality loss of OAuth credentials — including refresh_token, client_secret, and private-key JWT assertions — sent to an attacker-controlled server, enabling the attacker to impersonate the victim client against legitimate authorization servers and any downstream APIs protected by those credentials. There is no integrity or availability impact directly from the vulnerability itself, but stolen credentials could enable lateral movement to any resource the compromised OAuth client had access to. Only HTTP-based MCP clients are affected; stdio-based clients and MCP servers built with the SDK are not vulnerable (Github Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the advisory date. The EPSS score is approximately 0.176% (7th percentile), indicating a low near-term exploitation probability (Github Advisory). The vulnerability is rated automatable by NVD SSVC (no privileges required, no user interaction, network-accessible), meaning a malicious MCP server could silently harvest credentials from any connecting client at scale. It is not currently listed in the CISA Known Exploited Vulnerabilities catalog.

1. Set up a malicious MCP server: Deploy an HTTP-based MCP server that the target client will connect to, either by operating a publicly accessible server or by compromising a legitimate one.
2. Craft protected resource metadata: Configure the MCP server's protected resource metadata (e.g., /.well-known/oauth-protected-resource) to advertise an attacker-controlled authorization server URL as the required authorization server.
3. Wait for client connection: When a vulnerable MCP client (using @modelcontextprotocol/sdk 1.12.0–1.30.1 or @modelcontextprotocol/client 2.0.0–2.1.0) connects over HTTP, the SDK reads the server's advertised authorization server without validating it against stored credential bindings.
4. Receive harvested credentials: The client automatically sends its stored refresh_token and client_secret (or signed JWT assertion from a bundled provider) to the attacker's authorization server endpoint, with no user interaction required.
5. Exploit stolen credentials: Use the harvested refresh_token or client_secret against the legitimate authorization server to obtain valid access tokens and impersonate the victim client against protected APIs (Github Advisory, PR #2887).

• Network: Outbound OAuth token requests (HTTP POST to /token endpoints) from MCP client hosts to unexpected or unknown authorization server URLs; connections to authorization server domains not matching the legitimate IdP.
• Logs: MCP client logs showing AuthorizationServerMismatchError after upgrading (indicates a prior mismatch attempt); application logs recording token requests to unfamiliar issuer URLs; [mcp-sdk] SEP-2352: stored OAuth credential has no 'issuer' stamp console warnings indicating pre-upgrade credentials in use.
• Application Behavior: Unexpected authentication failures against legitimate APIs (suggesting tokens were consumed by an attacker); OAuth refresh token invalidation or client secret rotation events not initiated by the organization.

Upgrade to @modelcontextprotocol/sdk 1.31.0 (1.x) or @modelcontextprotocol/client 2.2.0 + @modelcontextprotocol/core 2.2.0 (2.x), which bind credentials to their authorization server via an issuer stamp (Github Advisory, v2.2.0 Release). After upgrading, additional steps are required: pass expectedIssuer: 'https://auth.example.com' to all bundled providers (ClientCredentialsProvider, PrivateKeyJwtProvider, StaticPrivateKeyJwtProvider, CrossAppAccessProvider); clear or re-stamp any credentials persisted before the upgrade (they lack the issuer field and remain unbound); and ensure custom OAuthClientProvider implementations round-trip the issuer field in saveTokens() and saveClientInformation(). As a workaround for those who cannot upgrade, restrict OAuth clients to connect only to fully trusted MCP servers. If an affected client may have connected to an untrusted server, rotate the client secret or signing key and revoke all tokens immediately.

The vulnerability was reported by seven independent researchers (Aviral2642, AlexMelanFromRingo, Gal3m, JosephDoUrden, Igfray, OriginalKazdov, lwebmedia), indicating broad community attention to MCP OAuth security (Github Advisory). Brief social media coverage appeared on Mastodon and Bluesky via TheHackerWire shortly after disclosure. Tenable published container security detection plugins (IDs 473469, 473540, 473832) and GitLab's advisory tracker also indexed the vulnerability, reflecting standard vendor ecosystem response.