MCP TypeScript SDK is the official TypeScript SDK for Model Context Protocol servers and clients. Starting in version 1.12.0 and prior to versions 1.31.0 and 2.2.0, the SDK's OAuth client support let the MCP server a client connected to decide which authorization server received the client's OAuth credentials. Stored and pre-provisioned credentials were not bound to the authorization server they belong to. A malicious or compromised MCP server could name its own authorization server in its protected resource metadata. Without any user interaction, the client would send that server the `refresh_token` and `client_secret` stored from an earlier sign-in (1.x), or the configured `client_secret` or signed assertion of a bundled non-interactive provider (1.x and 2.x). Only those applications that use the SDK as an MCP client over HTTP with an `authProvider`: your own `OAuthClientProvider`, or the bundled `ClientCredentialsProvider`, `PrivateKeyJwtProvider`, `StaticPrivateKeyJwtProvider` or (2.x) `CrossAppAccessProvider` and that may connect to an MCP server the owners does not fully trust while holding credentials for a legitimate authorization server are affected. `@modelcontextprotocol/sdk` 1.31.0 (1.x) and `@modelcontextprotocol/client` 2.2.0 (2.x) patch the issue. A workaround for those who cannot upgrade is available. 2.0.0 and 2.1.0 already accept `expectedIssuer`. On 1.x, the only workaround is to connect OAuth-enabled clients only to MCP servers you trust.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - MCP TypeScript SDK is the official TypeScript SDK for Model Context Protocol servers and clients. Starting
    in version 1.12.0 and prior to versions 1.31.0 and 2.2.0, the SDK's OAuth client support let the MCP
    server a client connected to decide which authorization server received the client's OAuth credentials.
    Stored and pre-provisioned credentials were not bound to the authorization server they belong to. A
    malicious or compromised MCP server could name its own authorization server in its protected resource
    metadata. Without any user interaction, the client would send that server the `refresh_token` and
    `client_secret` stored from an earlier sign-in (1.x), or the configured `client_secret` or signed
    assertion of a bundled non-interactive provider (1.x and 2.x). Only those applications that use the SDK as
    an MCP client over HTTP with an `authProvider`: your own `OAuthClientProvider`, or the bundled
    `ClientCredentialsProvider`, `PrivateKeyJwtProvider`, `StaticPrivateKeyJwtProvider` or (2.x)
    `CrossAppAccessProvider` and that may connect to an MCP server the owners does not fully trust while
    holding credentials for a legitimate authorization server are affected. `@modelcontextprotocol/sdk` 1.31.0
    (1.x) and `@modelcontextprotocol/client` 2.2.0 (2.x) patch the issue. A workaround for those who cannot
    upgrade is available. 2.0.0 and 2.1.0 already accept `expectedIssuer`. On 1.x, the only workaround is to
    connect OAuth-enabled clients only to MCP servers you trust. (CVE-2026-104850)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - MCP TypeScript SDK is the official TypeScript SDK for Model Context Protocol servers and clients. Starting     in version 1.12.0 and prior to versions 1.31.0 and 2.2.0, the SDK's OAuth client support let the MCP     server a client connected to decide which authorization server received the client's OAuth credentials.
    Stored and pre-provisioned credentials were not bound to the authorization server they belong to. A     malicious or compromised MCP server could name its own authorization server in its protected resource     metadata. Without any user interaction, the client would send that server the `refresh_token` and     `client_secret` stored from an earlier sign-in (1.x), or the configured `client_secret` or signed     assertion of a bundled non-interactive provider (1.x and 2.x). Only those applications that use the SDK as     an MCP client over HTTP with an `authProvider`: your own `OAuthClientProvider`, or the bundled     `ClientCredentialsProvider`, `PrivateKeyJwtProvider`, `StaticPrivateKeyJwtProvider` or (2.x)     `CrossAppAccessProvider` and that may connect to an MCP server the owners does not fully trust while     holding credentials for a legitimate authorization server are affected. `@modelcontextprotocol/sdk` 1.31.0     (1.x) and `@modelcontextprotocol/client` 2.2.0 (2.x) patch the issue. A workaround for those who cannot     upgrade is available. 2.0.0 and 2.1.0 already accept `expectedIssuer`. On 1.x, the only workaround is to     connect OAuth-enabled clients only to MCP servers you trust. (CVE-2026-104850)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
473540	Echo: @modelcontextprotocol/sdk: security update to 1.31.0	Tenable Cloud Security	Echo Local Security Checks	Local	high
473540	Echo: @modelcontextprotocol/sdk: security update to 1.31.0	Tenable Self-Hosted Container Security	Echo Local Security Checks	Local	high
473469	SCA: security update for @modelcontextprotocol/client, @modelcontextprotocol/sdk (GHSA-6qxp-vccf-f47h)	Tenable Cloud Security	SCA Checks	Local	high
473469	SCA: security update for @modelcontextprotocol/client, @modelcontextprotocol/sdk (GHSA-6qxp-vccf-f47h)	Tenable Self-Hosted Container Security	SCA Checks	Local	high
363805	Linux Distros Unpatched Vulnerability : CVE-2026-104850	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-104850

high

Tenable Plugins

high

high

high

high

high