{"id":"CVE-2026-104850","aliases":["CLSA-2026-1791626582","CLSA-2026-1791679180","CLSA-2026-1791835900","CLSA-2026-1791839313","CLSA-2026-1792257408","CLSA-2026-1792262854","CLSA-2026-1792263903","CLSA-2026-1793112371","CLSA-2026-1793207764","EUVD-2026-93491","GHSA-6qxp-vccf-f47h","ROOT-APP-NPM-CVE-2026-104850"],"status":"published","title":"MCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP server","description":"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.","severity":{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00282,"percentile":0.20985,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":true,"fix_available":true},"cwes":["CWE-345","CWE-522"],"published":"2026-10-06T15:35:44Z","modified":"2026-10-30T19:46:05Z","exploits":[{"source":"pocgithub","id":"Iceman2050/mcp-oauth-discovery-prober","title":"Iceman2050/mcp-oauth-discovery-prober","date":"2026-10-17","url":"https://github.com/Iceman2050/mcp-oauth-discovery-prober"}],"fixes":[{"ecosystem":"npm","package":"@modelcontextprotocol/sdk","fixed_in":["1.31.0"],"sources":["ghsa","osv"]},{"ecosystem":"npm","package":"@modelcontextprotocol/client","fixed_in":["2.2.0"],"sources":["ghsa","osv"]},{"ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","fixed_in":["1.30.1-tuxcare.1","1.30.0-tuxcare.1","1.29.0-tuxcare.1","1.26.0-tuxcare.1","1.17.3-tuxcare.3","1.24.0-tuxcare.3","1.25.2-tuxcare.3"],"sources":["osv"]},{"ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/client","fixed_in":["2.0.0-tuxcare.1"],"sources":["osv"]},{"ecosystem":"Root:npm","package":"@modelcontextprotocol/sdk","fixed_in":["1.26.0-aikido.1","1.30.0-aikido.1","1.29.0-aikido.1","1.30.0-aikido.2","1.26.0-aikido.2","1.29.0-aikido.2","1.26.0-aikido.3","1.26.0-aikido.4","1.31.0-aikido.1"],"sources":["osv"]},{"ecosystem":"Root:npm","package":"@rootio/modelcontextprotocol__sdk","fixed_in":["1.26.0-root.io.1","1.30.0-root.io.1","1.29.0-root.io.1","1.30.0-root.io.2","1.26.0-root.io.2","1.29.0-root.io.2","1.26.0-root.io.3","1.26.0-root.io.4","1.31.0-root.io.1"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.12.0"},{"fixed":"1.31.0"}]}]},{"source":"ghsa","ecosystem":"npm","package":"@modelcontextprotocol/client","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.0.0"},{"fixed":"2.2.0"}]}]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.30.1-tuxcare.0"},{"fixed":"1.30.1-tuxcare.1"}]}],"versions":["1.30.1"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.30.0-tuxcare.0"},{"fixed":"1.30.0-tuxcare.1"}]}],"versions":["1.30.0"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.29.0-tuxcare.0"},{"fixed":"1.29.0-tuxcare.1"}]}],"versions":["1.29.0"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.26.0-tuxcare.0"},{"fixed":"1.26.0-tuxcare.1"}]}],"versions":["1.26.0"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.17.3-tuxcare.0"},{"fixed":"1.17.3-tuxcare.3"}]}],"versions":["1.17.3","1.17.3-tuxcare.1","1.17.3-tuxcare.2"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.24.0-tuxcare.0"},{"fixed":"1.24.0-tuxcare.3"}]}],"versions":["1.24.0","1.24.0-tuxcare.1","1.24.0-tuxcare.2"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.25.2-tuxcare.0"},{"fixed":"1.25.2-tuxcare.3"}]}],"versions":["1.25.2","1.25.2-tuxcare.1","1.25.2-tuxcare.2"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.13.3-tuxcare.0"},{"fixed":"1.13.3-tuxcare.2"}]}],"versions":["1.13.3","1.13.3-tuxcare.1"],"bundled":6},{"source":"osv","ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/client","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.0.0-tuxcare.0"},{"fixed":"2.0.0-tuxcare.1"}]}],"versions":["2.0.0"]},{"source":"osv","ecosystem":"npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"SEMVER","events":[{"introduced":"1.12.0"},{"fixed":"1.31.0"}]}]},{"source":"osv","ecosystem":"npm","package":"@modelcontextprotocol/client","ranges":[{"type":"SEMVER","events":[{"introduced":"2.0.0"},{"fixed":"2.2.0"}]}]},{"source":"osv","ecosystem":"Root:npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.26.0-aikido.1"},{"fixed":"1.30.0-aikido.1"},{"fixed":"1.29.0-aikido.1"},{"fixed":"1.30.0-aikido.2"},{"fixed":"1.26.0-aikido.2"},{"fixed":"1.29.0-aikido.2"},{"fixed":"1.26.0-aikido.3"},{"fixed":"1.26.0-aikido.4"},{"fixed":"1.31.0-aikido.1"}]}]},{"source":"osv","ecosystem":"Root:npm","package":"@rootio/modelcontextprotocol__sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.26.0-root.io.1"},{"fixed":"1.30.0-root.io.1"},{"fixed":"1.29.0-root.io.1"},{"fixed":"1.30.0-root.io.2"},{"fixed":"1.26.0-root.io.2"},{"fixed":"1.29.0-root.io.2"},{"fixed":"1.26.0-root.io.3"},{"fixed":"1.26.0-root.io.4"},{"fixed":"1.31.0-root.io.1"}]}]}],"products":[{"vendor":"modelcontextprotocol","product":"typescript-sdk"}],"references":[{"url":"https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-6qxp-vccf-f47h","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/modelcontextprotocol/typescript-sdk/pull/2887","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/modelcontextprotocol/typescript-sdk/commit/edd12e282620ebf770d67316f19cf91d4112a1bd","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/modelcontextprotocol/typescript-sdk/releases/tag/v2.2.0","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/advisories/GHSA-6qxp-vccf-f47h"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/104xxx/CVE-2026-104850.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-104850","tags":["advisory"]},{"url":"https://github.com/modelcontextprotocol/typescript-sdk","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-104850","title":"MCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP server","description":"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.","status":"published","published":"2026-10-06T16:08:21.514Z","modified":"2026-10-06T16:28:53.097Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N","level":"high","assessor":"cna"}],"cwes":["CWE-345","CWE-522"],"updated_at":"2026-11-02T14:20:09.098623Z"}],"euvd":[{"id":"EUVD-2026-93491","description":"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.","status":"published","published":"2026-10-06T16:08:21Z","modified":"2026-10-06T16:28:53Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N","level":"high"}],"updated_at":"2026-11-02T17:27:37.480805Z"}],"ghsa":[{"id":"GHSA-6qxp-vccf-f47h","title":"MCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP server","description":"### Summary\nIn 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.\n\nA malicious or compromised MCP server could name its own authorization server. With no user interaction, the client would send it:\n\n- the `refresh_token` and `client_secret` stored from an earlier sign-in\n- the `client_secret` or signed assertion configured on a bundled provider\n\n### Am I affected?\nYes, if both of these hold:\n\n- your application uses the SDK's OAuth client over HTTP, through any of:\n    - an `authProvider` on a transport\n    - the `withOAuth()` middleware\n    - direct calls to `auth()` or `fetchToken()`\n- it may connect to an MCP server you do not fully trust while holding credentials for a legitimate authorization server\n\nAffected versions:\n\n- `@modelcontextprotocol/sdk` 1.12.0 through 1.30.1\n- `@modelcontextprotocol/client` 2.0.0 through 2.1.0, only for:\n    - bundled providers without `expectedIssuer`\n    - credentials stored or supplied without `issuer`\n    - direct calls to `fetchToken()`\n    - providers that read storage back through `OAuthTokensSchema` or `OAuthClientInformationSchema`\n\nNot affected:\n\n- MCP servers built with the SDK\n- stdio clients\n\n### Fix\nUpgrade to:\n\n- 1.x: `@modelcontextprotocol/sdk` 1.31.0 or later\n- 2.x: `@modelcontextprotocol/client` 2.2.0 or later, and `@modelcontextprotocol/core` 2.2.0 or later if you import it directly\n\nThe 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.\n\nIn the following cases, upgrading to the patched version is not enough. You also need to make a change:\n\n- **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.\n- **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.\n- **Your own `OAuthClientProvider`:** save exactly what `saveTokens()` and `saveClientInformation()` are given, including `issuer`. For pre-registered credentials, include `issuer` in what `clientInformation()` returns.\n\nNot covered by this fix:\n\n- a new interactive sign-in, which still goes to the authorization server the MCP server names. Only complete sign-ins for servers you trust.\n- `refreshAuthorization()` and `exchangeAuthorization()` called directly\n- 2.x with `skipIssuerMetadataValidation: true`\n\nIf an affected client may have connected to an untrusted MCP server, rotate its client secret or signing key and revoke its tokens.\n\nIf you cannot upgrade yet, connect OAuth clients only to MCP servers you trust. 2.0.0 and 2.1.0 already accept `expectedIssuer`.","status":"published","published":"2026-10-06T15:35:44Z","modified":"2026-10-06T15:35:44Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N","level":"high"}],"cwes":["CWE-345","CWE-522"],"updated_at":"2026-11-02T14:41:27.036917Z"}],"nvd":[{"id":"CVE-2026-104850","description":"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.","status":"published","published":"2026-10-06T17:17:15.827Z","modified":"2026-10-06T20:03:40.69Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N","level":"high","assessor":"secondary"}],"cwes":["CWE-345","CWE-522"],"updated_at":"2026-11-02T14:12:54.486849Z"}],"osv":[{"id":"CVE-2026-104850","title":"MCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP server","description":"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.","status":"published","published":"2026-10-06T16:08:21.514Z","modified":"2026-11-11T10:47:23.254292864Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N","level":"high"}],"cwes":["CWE-345","CWE-522"],"updated_at":"2026-11-11T03:22:04.464623Z"},{"id":"GHSA-6qxp-vccf-f47h","title":"MCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP server","description":"### Summary\nIn 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.\n\nA malicious or compromised MCP server could name its own authorization server. With no user interaction, the client would send it:\n\n- the `refresh_token` and `client_secret` stored from an earlier sign-in\n- the `client_secret` or signed assertion configured on a bundled provider\n\n### Am I affected?\nYes, if both of these hold:\n\n- your application uses the SDK's OAuth client over HTTP, through any of:\n    - an `authProvider` on a transport\n    - the `withOAuth()` middleware\n    - direct calls to `auth()` or `fetchToken()`\n- it may connect to an MCP server you do not fully trust while holding credentials for a legitimate authorization server\n\nAffected versions:\n\n- `@modelcontextprotocol/sdk` 1.12.0 through 1.30.1\n- `@modelcontextprotocol/client` 2.0.0 through 2.1.0, only for:\n    - bundled providers without `expectedIssuer`\n    - credentials stored or supplied without `issuer`\n    - direct calls to `fetchToken()`\n    - providers that read storage back through `OAuthTokensSchema` or `OAuthClientInformationSchema`\n\nNot affected:\n\n- MCP servers built with the SDK\n- stdio clients\n\n### Fix\nUpgrade to:\n\n- 1.x: `@modelcontextprotocol/sdk` 1.31.0 or later\n- 2.x: `@modelcontextprotocol/client` 2.2.0 or later, and `@modelcontextprotocol/core` 2.2.0 or later if you import it directly\n\nThe 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.\n\nIn the following cases, upgrading to the patched version is not enough. You also need to make a change:\n\n- **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.\n- **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.\n- **Your own `OAuthClientProvider`:** save exactly what `saveTokens()` and `saveClientInformation()` are given, including `issuer`. For pre-registered credentials, include `issuer` in what `clientInformation()` returns.\n\nNot covered by this fix:\n\n- a new interactive sign-in, which still goes to the authorization server the MCP server names. Only complete sign-ins for servers you trust.\n- `refreshAuthorization()` and `exchangeAuthorization()` called directly\n- 2.x with `skipIssuerMetadataValidation: true`\n\nIf an affected client may have connected to an untrusted MCP server, rotate its client secret or signing key and revoke its tokens.\n\nIf you cannot upgrade yet, connect OAuth clients only to MCP servers you trust. 2.0.0 and 2.1.0 already accept `expectedIssuer`.","status":"published","published":"2026-10-06T15:35:44Z","modified":"2026-10-06T15:46:47.143033168Z","cvss":[{"version":"3.1","score":7.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N","level":"high"}],"cwes":["CWE-345","CWE-522"],"updated_at":"2026-11-02T15:46:39.965326Z"},{"id":"CLSA-2026-1791626582","title":"TuxCare security update for @modelcontextprotocol/sdk (1 CVE)","description":"TuxCare rebuilt @modelcontextprotocol/sdk to address 1 CVE. Fixed in 1.30.1-tuxcare.1.","status":"published","published":"2026-10-10T10:03:02Z","modified":"2026-10-15T09:48:04.603878859Z","updated_at":"2026-11-02T15:43:50.599064Z"},{"id":"CLSA-2026-1791679180","title":"TuxCare security update for @modelcontextprotocol/sdk (1 CVE)","description":"TuxCare rebuilt @modelcontextprotocol/sdk to address 1 CVE. Fixed in 1.30.0-tuxcare.1.","status":"published","published":"2026-10-11T00:39:40Z","modified":"2026-10-15T09:47:39.719025523Z","updated_at":"2026-11-02T15:43:50.599064Z"},{"id":"CLSA-2026-1791835900","title":"TuxCare security update for @modelcontextprotocol/sdk (1 CVE)","description":"TuxCare rebuilt @modelcontextprotocol/sdk to address 1 CVE. Fixed in 1.29.0-tuxcare.1.","status":"published","published":"2026-10-12T20:11:40Z","modified":"2026-10-15T09:47:53.489238824Z","updated_at":"2026-11-02T15:43:50.599064Z"},{"id":"CLSA-2026-1791839313","title":"TuxCare security update for @modelcontextprotocol/sdk (1 CVE)","description":"TuxCare rebuilt @modelcontextprotocol/sdk to address 1 CVE. Fixed in 1.26.0-tuxcare.1.","status":"published","published":"2026-10-12T21:08:33Z","modified":"2026-10-15T09:47:53.555581487Z","updated_at":"2026-11-02T15:43:50.599064Z"},{"id":"CLSA-2026-1792257408","title":"TuxCare security update for @modelcontextprotocol/sdk (1 CVE)","description":"TuxCare rebuilt @modelcontextprotocol/sdk to address 1 CVE. Fixed in 1.17.3-tuxcare.3.","status":"published","published":"2026-10-17T17:16:48Z","modified":"2026-10-30T19:45:12.962689629Z","updated_at":"2026-11-02T15:43:52.288832Z"},{"id":"CLSA-2026-1792262854","title":"TuxCare security update for @modelcontextprotocol/sdk (1 CVE)","description":"TuxCare rebuilt @modelcontextprotocol/sdk to address 1 CVE. Fixed in 1.24.0-tuxcare.3.","status":"published","published":"2026-10-17T18:47:34Z","modified":"2026-10-30T19:46:05.844755693Z","updated_at":"2026-11-02T15:43:52.288832Z"},{"id":"CLSA-2026-1792263903","title":"TuxCare security update for @modelcontextprotocol/sdk (1 CVE)","description":"TuxCare rebuilt @modelcontextprotocol/sdk to address 1 CVE. Fixed in 1.25.2-tuxcare.3.","status":"published","published":"2026-10-17T19:05:03Z","modified":"2026-10-30T19:46:05.844876935Z","updated_at":"2026-11-02T15:43:52.288832Z"},{"id":"CLSA-2026-1793112371","title":"TuxCare security update for @modelcontextprotocol/sdk (6 CVEs)","description":"TuxCare rebuilt @modelcontextprotocol/sdk to address 6 CVEs. Fixed in 1.13.3-tuxcare.2.","status":"published","published":"2026-10-27T14:46:11Z","modified":"2026-10-30T19:45:13.789904458Z","updated_at":"2026-11-02T15:43:55.34846Z"},{"id":"CLSA-2026-1793207764","title":"TuxCare security update for @modelcontextprotocol/client (1 CVE)","description":"TuxCare rebuilt @modelcontextprotocol/client to address 1 CVE. Fixed in 2.0.0-tuxcare.1.","status":"published","published":"2026-10-28T17:16:04Z","modified":"2026-10-28T19:45:10.20116367Z","updated_at":"2026-11-02T15:43:55.669514Z"},{"id":"ROOT-APP-NPM-CVE-2026-104850","title":"CVE-2026-104850 in @modelcontextprotocol/sdk - Patched by Root","description":"Root has patched CVE-2026-104850 in the @modelcontextprotocol/sdk package for Root:npm. Multiple fixed versions available.","status":"published","published":"2026-10-30T08:51:21Z","modified":"2026-10-30T09:15:36.887419684Z","updated_at":"2026-11-02T15:53:27.362922Z"}]}}