A malicious MCP server could make the MCP TypeScript SDK send your OAuth credentials to a server it controls. The flaw, CVE-2026-104850 (GHSA-6qxp-vccf-f47h), is rated high (CVSS 7.5). If you build or run an MCP client on @modelcontextprotocol/sdk that connects to remote servers over OAuth, upgrade and check the steps below.
| Question | Short answer |
|---|---|
| Am I affected? | If your client uses @modelcontextprotocol/sdk 1.12.0 to 1.30.1, or @modelcontextprotocol/client 2.0.0 to 2.1.0 in narrower configurations, and connects to remote HTTP servers |
| Is there a fix? | Yes: sdk 1.31.0, client 2.2.0 (and core 2.2.0 if imported directly) |
| Are servers or stdio clients affected? | No, per the advisory |
| Does data leave my machine? | Only if your client connected to an untrusted server, which is the attack |
| Is upgrading enough? | No. Set expectedIssuer, fix saved credentials, rotate if exposed |
How the attack works
In the MCP authorization flow, a server tells the client where its authorization server lives. The MCP authorization spec has clients discover that through OAuth Protected Resource Metadata. The spec also says clients must record the expected issuer and must not send tokens other than ones issued by the MCP server's own authorization server.
According to the advisory, the vulnerable SDK did not hold the line. A malicious or compromised server could name an authorization server of its choosing, and the client would then send stored credentials there, with no user prompt. Exposed material includes the refresh token and client secret, or the client secret or signed assertion of a bundled provider.
The practical path: a user or agent adds a remote MCP server that looks harmless, or a trusted one is compromised. On the next connection, the client talks to the attacker's authorization server instead. The attacker now holds a refresh token that may work against the real service.
Who is affected
| Package | Affected | Fixed |
|---|---|---|
@modelcontextprotocol/sdk | 1.12.0 – 1.30.1 | 1.31.0 |
@modelcontextprotocol/client | 2.0.0 – 2.1.0 (narrower configurations) | 2.2.0 |
@modelcontextprotocol/core | imported directly | 2.2.0 |
What this means if you run AI coding agents
The advisory concerns applications that use the SDK's OAuth client, so the direct risk is to anyone building MCP clients, agent harnesses or internal tooling on the TypeScript SDK. The advisory does not say which off-the-shelf agents embed the SDK, so check any tool you build or ship, and watch for vendor updates from the tools you use.
- Find the version. Run
npm ls @modelcontextprotocol/sdkandnpm ls @modelcontextprotocol/clientin each project that embeds an MCP client. - Upgrade to sdk 1.31.0 or client 2.2.0.
- Bundled providers: set
expectedIssuer, for exampleexpectedIssuer: 'https://auth.example.com'. - Saved credentials: add an
issuerfield to them, or clear them so users sign in again. - Custom
OAuthClientProvider: persist theissuervalue passed tosaveTokens()andsaveClientInformation(). - If the client may have connected to an untrusted server: rotate its client secret or signing key and revoke its tokens.
Know what the fix leaves open. New interactive sign-ins still go to whichever authorization server the MCP server names, so only finish them with servers you trust. Direct calls to refreshAuthorization() and exchangeAuthorization(), and 2.x setups using skipIssuerMetadataValidation: true, are not covered.
To tell if you were hit, look for OAuth requests from your client to authorization hosts you do not recognise, and for unexpected use of your refresh tokens at the provider. The advisory does not describe in-the-wild exploitation.
What Beam can and cannot do here
Beam cannot see inside your own client's OAuth code or dependency tree, and it will not flag this CVE. What it does offer is a pre-connect review habit: beam scan .mcp.json --mcp checks an MCP config for risky patterns and version pinning without launching the servers. That helps you notice unfamiliar remote servers before an agent connects. The scan is heuristic and cannot judge a server's runtime behaviour. For the review process, see MCP security: review servers before connecting your agent and the practical MCP guide.
Why this matters beyond one SDK
Remote MCP servers are untrusted input that now sits on an authentication path. The same lesson showed up in agentjacking via an MCP server and in Cursor MCP config poisoning: the thing you connect to can steer the client. Treat every server entry as a trust decision, and see the wider supply-chain picture.
Frequently asked questions
What is CVE-2026-104850?
It is a high-severity (CVSS 7.5) flaw in the MCP TypeScript SDK OAuth client. A malicious or compromised MCP server could name its own authorization server, and the client would send stored credentials to it without user interaction.
Which versions are affected and which are fixed?
@modelcontextprotocol/sdk 1.12.0 through 1.30.1 is affected and 1.31.0 is fixed. @modelcontextprotocol/client 2.0.0 through 2.1.0 is affected in narrower configurations and 2.2.0 is fixed.
Are MCP servers or stdio clients affected?
No. The advisory says MCP servers built with the SDK and stdio clients are not affected. The risk is in OAuth clients that connect to remote HTTP MCP servers.
Is upgrading enough?
Not always. Bundled providers should set expectedIssuer, saved credentials need an issuer field or must be cleared, and anything that may have reached an untrusted server should be rotated and revoked.
What does the fix not cover?
New interactive sign-ins still go to whichever authorization server the MCP server names. Direct calls to refreshAuthorization() and exchangeAuthorization(), and 2.x setups with skipIssuerMetadataValidation: true, are also outside the fix.
Can Beam detect this vulnerability?
No. Beam scans MCP config files with heuristics and a version-pin check, but it does not read the dependency tree of your own MCP client code. Use npm ls to check the SDK version.
Related reading
- MCP security: review servers before connecting your agent
- MCP security practical guide
- Agentjacking through an MCP server
- Official advisory and MCP authorization specification
Versions and advisory details are accurate as of October 13, 2026. Check the advisory for later changes.