{"id":"CVE-2026-111771","aliases":["CLSA-2026-1793100011","CLSA-2026-1793110244","CLSA-2026-1793112043","CLSA-2026-1793112371","CLSA-2026-1793113170","CLSA-2026-1793887845","CLSA-2026-1793887992","CLSA-2026-1793887996","EUVD-2026-117801","GHSA-rvq5-wwqv-78pq"],"status":"published","title":"Model Context Protocol TypeScript SDK: Server bearer authentication accepted tokens issued for another service","description":"The Model Context Protocol TypeScript SDK provides TypeScript client and server implementations of the Model Context Protocol. From 1.6.0 until 1.32.0 in @modelcontextprotocol/sdk, from 2.0.0 until 2.3.0 in @modelcontextprotocol/server, from 2.0.0 until 2.0.2 in @modelcontextprotocol/express, and from 2.0.0 until 2.3.1 in @modelcontextprotocol/server-legacy, server-side bearer authentication could accept a valid access token issued for a different service because the SDK did not enforce the token audience. The affected surface is server-side HTTP bearer authentication. The trigger is a valid token whose audience names another service. The authorization server must issue tokens for multiple services, and the application's verifyAccessToken() must not independently validate aud. Applications already validating aud inside verifyAccessToken() are not affected. An attacker with a token for another service could authenticate to the MCP server and obtain the confidentiality and integrity capabilities granted to an authenticated caller. Upgrading alone leaves the new audience validation disabled. Operators must enable audience validation and provide the token audience together. Enabling only the expected audience check causes every request to receive HTTP 401. This issue is fixed in @modelcontextprotocol/sdk 1.32.0, @modelcontextprotocol/server 2.3.0, @modelcontextprotocol/express 2.0.2, and @modelcontextprotocol/server-legacy 2.3.1.","severity":{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00541,"percentile":0.4601,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-863"],"published":"2026-10-20T19:43:36Z","modified":"2026-11-06T13:15:18Z","fixes":[{"ecosystem":"npm","package":"@modelcontextprotocol/sdk","fixed_in":["1.32.0"],"sources":["ghsa","osv"]},{"ecosystem":"npm","package":"@modelcontextprotocol/server","fixed_in":["2.3.0"],"sources":["ghsa","osv"]},{"ecosystem":"npm","package":"@modelcontextprotocol/express","fixed_in":["2.0.2"],"sources":["ghsa","osv"]},{"ecosystem":"npm","package":"@modelcontextprotocol/server-legacy","fixed_in":["2.3.1"],"sources":["ghsa","osv"]},{"ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","fixed_in":["1.29.0-tuxcare.4","1.26.0-tuxcare.4"],"sources":["osv"]}],"affected":[{"source":"ghsa","ecosystem":"npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.6.0"},{"fixed":"1.32.0"}]}]},{"source":"ghsa","ecosystem":"npm","package":"@modelcontextprotocol/server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.0.0"},{"fixed":"2.3.0"}]}]},{"source":"ghsa","ecosystem":"npm","package":"@modelcontextprotocol/express","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.0.0"},{"fixed":"2.0.2"}]}]},{"source":"ghsa","ecosystem":"npm","package":"@modelcontextprotocol/server-legacy","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.0.0"},{"fixed":"2.3.1"}]}]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.30.0-tuxcare.0"},{"fixed":"1.30.0-tuxcare.2"}]}],"versions":["1.30.0","1.30.0-tuxcare.1"],"bundled":3},{"source":"osv","ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.29.0-tuxcare.0"},{"fixed":"1.29.0-tuxcare.4"}]}],"versions":["1.29.0","1.29.0-tuxcare.1","1.29.0-tuxcare.2","1.29.0-tuxcare.3"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.25.2-tuxcare.0"},{"fixed":"1.25.2-tuxcare.4"}]}],"versions":["1.25.2","1.25.2-tuxcare.1","1.25.2-tuxcare.2","1.25.2-tuxcare.3"],"bundled":4},{"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/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.24.0-tuxcare.0"},{"fixed":"1.24.0-tuxcare.4"}]}],"versions":["1.24.0","1.24.0-tuxcare.1","1.24.0-tuxcare.2","1.24.0-tuxcare.3"],"bundled":4},{"source":"osv","ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.26.0-tuxcare.0"},{"fixed":"1.26.0-tuxcare.4"}]}],"versions":["1.26.0","1.26.0-tuxcare.1","1.26.0-tuxcare.2","1.26.0-tuxcare.3"]},{"source":"osv","ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.30.1-tuxcare.0"},{"fixed":"1.30.1-tuxcare.3"}]}],"versions":["1.30.1","1.30.1-tuxcare.1","1.30.1-tuxcare.2"],"bundled":2},{"source":"osv","ecosystem":"TuxCare:npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.17.3-tuxcare.0"},{"fixed":"1.17.3-tuxcare.4"}]}],"versions":["1.17.3","1.17.3-tuxcare.1","1.17.3-tuxcare.2","1.17.3-tuxcare.3"],"bundled":3},{"source":"osv","ecosystem":"npm","package":"@modelcontextprotocol/sdk","ranges":[{"type":"SEMVER","events":[{"introduced":"1.6.0"},{"fixed":"1.32.0"}]}]},{"source":"osv","ecosystem":"npm","package":"@modelcontextprotocol/server","ranges":[{"type":"SEMVER","events":[{"introduced":"2.0.0"},{"fixed":"2.3.0"}]}]},{"source":"osv","ecosystem":"npm","package":"@modelcontextprotocol/express","ranges":[{"type":"SEMVER","events":[{"introduced":"2.0.0"},{"fixed":"2.0.2"}]}]},{"source":"osv","ecosystem":"npm","package":"@modelcontextprotocol/server-legacy","ranges":[{"type":"SEMVER","events":[{"introduced":"2.0.0"},{"fixed":"2.3.1"}]}]}],"products":[{"vendor":"@clerk","product":"express"},{"vendor":"@modelcontextprotocol","product":"express"},{"vendor":"@modelcontextprotocol","product":"sdk"},{"vendor":"@modelcontextprotocol","product":"server"},{"vendor":"@modelcontextprotocol","product":"server-legacy"},{"vendor":"devolutions","product":"server"},{"vendor":"modelcontextprotocol","product":"typescript-sdk"},{"vendor":"redwoodjs","product":"sdk"}],"references":[{"url":"https://github.com/modelcontextprotocol/typescript-sdk/security/advisories/GHSA-rvq5-wwqv-78pq","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/modelcontextprotocol/typescript-sdk/pull/2929","tags":["x_refsource_MISC","fix"]},{"url":"https://github.com/modelcontextprotocol/typescript-sdk/pull/2930","tags":["x_refsource_MISC","fix"]},{"url":"https://github.com/modelcontextprotocol/typescript-sdk/pull/2952","tags":["x_refsource_MISC","fix"]},{"url":"https://github.com/modelcontextprotocol/typescript-sdk/commit/40f8f4e229d963cd7fd2890bda2aeebe7005299a","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/modelcontextprotocol/typescript-sdk/commit/5a0724d14cf34a27a3b070224d2996cdd611df9f","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/modelcontextprotocol/typescript-sdk/commit/5a1867390b91b8836f49af76c45427279f513325","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/modelcontextprotocol/typescript-sdk/releases/tag/1.32.0","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/modelcontextprotocol/typescript-sdk/releases/tag/@modelcontextprotocol/express@2.0.2","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/modelcontextprotocol/typescript-sdk/releases/tag/@modelcontextprotocol/server-legacy@2.3.1","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/modelcontextprotocol/typescript-sdk/releases/tag/@modelcontextprotocol/server@2.3.0","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/advisories/GHSA-rvq5-wwqv-78pq"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/111xxx/CVE-2026-111771.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-111771","tags":["advisory"]},{"url":"https://github.com/modelcontextprotocol/typescript-sdk","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-111771","title":"Model Context Protocol TypeScript SDK: Server bearer authentication accepted tokens issued for another service","description":"The Model Context Protocol TypeScript SDK provides TypeScript client and server implementations of the Model Context Protocol. From 1.6.0 until 1.32.0 in @modelcontextprotocol/sdk, from 2.0.0 until 2.3.0 in @modelcontextprotocol/server, from 2.0.0 until 2.0.2 in @modelcontextprotocol/express, and from 2.0.0 until 2.3.1 in @modelcontextprotocol/server-legacy, server-side bearer authentication could accept a valid access token issued for a different service because the SDK did not enforce the token audience. The affected surface is server-side HTTP bearer authentication. The trigger is a valid token whose audience names another service. The authorization server must issue tokens for multiple services, and the application's verifyAccessToken() must not independently validate aud. Applications already validating aud inside verifyAccessToken() are not affected. An attacker with a token for another service could authenticate to the MCP server and obtain the confidentiality and integrity capabilities granted to an authenticated caller. Upgrading alone leaves the new audience validation disabled. Operators must enable audience validation and provide the token audience together. Enabling only the expected audience check causes every request to receive HTTP 401. This issue is fixed in @modelcontextprotocol/sdk 1.32.0, @modelcontextprotocol/server 2.3.0, @modelcontextprotocol/express 2.0.2, and @modelcontextprotocol/server-legacy 2.3.1.","status":"published","published":"2026-11-05T21:08:55.758Z","modified":"2026-11-10T04:21:21.841Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-863"],"updated_at":"2026-11-10T05:37:08.449625Z"}],"euvd":[{"id":"EUVD-2026-117801","description":"The Model Context Protocol TypeScript SDK provides TypeScript client and server implementations of the Model Context Protocol. From 1.6.0 until 1.32.0 in @modelcontextprotocol/sdk, from 2.0.0 until 2.3.0 in @modelcontextprotocol/server, from 2.0.0 until 2.0.2 in @modelcontextprotocol/express, and from 2.0.0 until 2.3.1 in @modelcontextprotocol/server-legacy, server-side bearer authentication could accept a valid access token issued for a different service because the SDK did not enforce the token audience. The affected surface is server-side HTTP bearer authentication. The trigger is a valid token whose audience names another service. The authorization server must issue tokens for multiple services, and the application's verifyAccessToken() must not independently validate aud. Applications already validating aud inside verifyAccessToken() are not affected. An attacker with a token for another service could authenticate to the MCP server and obtain the confidentiality and integrity capabilities granted to an authenticated caller. Upgrading alone leaves the new audience validation disabled. Operators must enable audience validation and provide the token audience together. Enabling only the expected audience check causes every request to receive HTTP 401. This issue is fixed in @modelcontextprotocol/sdk 1.32.0, @modelcontextprotocol/server 2.3.0, @modelcontextprotocol/express 2.0.2, and @modelcontextprotocol/server-legacy 2.3.1.","status":"published","published":"2026-11-05T21:08:55Z","modified":"2026-11-10T04:21:21Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N","level":"medium"}],"updated_at":"2026-11-10T05:19:59.129782Z"}],"ghsa":[{"id":"GHSA-rvq5-wwqv-78pq","title":"MCP TypeScript SDK: Server bearer authentication accepted tokens issued for another service","description":"### Summary\nIn affected versions, the SDK's server-side bearer authentication had no way to check that a token was issued for your server (its audience). Where one authorization server issues tokens for several services, a valid token for another service was also accepted by your MCP server.\n\n### Am I affected?\nYes, if your HTTP server uses `requireBearerAuth()` or `verifyBearerToken()`, its authorization server also issues tokens for other services, and your `verifyAccessToken()` does not check the token's audience (`aud`) itself.\n\nAffected versions:\n\n- `@modelcontextprotocol/sdk` 1.6.0 through 1.31.0\n- `@modelcontextprotocol/server` 2.0.0 through 2.2.0\n- `@modelcontextprotocol/express` 2.0.0 through 2.0.1\n- `@modelcontextprotocol/server-legacy` 2.0.0 through 2.3.0\n\n### Fix\nUpgrade to:\n\n- 1.x: `@modelcontextprotocol/sdk` 1.32.0 or later\n- 2.x: `@modelcontextprotocol/server` 2.3.0 or later, together with `@modelcontextprotocol/express` 2.0.2 or later if you use it\n- `@modelcontextprotocol/server-legacy` 2.3.1 or later\n\n**Upgrading alone changes nothing.** The patched versions add an `expectedResource` setting that is off by default. To turn the check on, make both of these changes together:\n\n1. Pass the audience your authorization server puts in tokens for your server: `requireBearerAuth({ verifier, expectedResource: new URL('https://mcp.example.com/mcp') })`.\n2. Return the token's audience from `verifyAccessToken()` as `AuthInfo.resource`, also a `URL`.\n\nA token for another service then gets `401`. With only the first change, every request gets `401`.\n\nIf you cannot upgrade yet, reject any token whose `aud` does not include your server inside `verifyAccessToken()`. That closes the issue on every version.","status":"published","published":"2026-10-20T19:43:36Z","modified":"2026-10-20T19:43:37Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N","level":"medium"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T14:41:33.669646Z"}],"nvd":[{"id":"CVE-2026-111771","description":"The Model Context Protocol TypeScript SDK provides TypeScript client and server implementations of the Model Context Protocol. From 1.6.0 until 1.32.0 in @modelcontextprotocol/sdk, from 2.0.0 until 2.3.0 in @modelcontextprotocol/server, from 2.0.0 until 2.0.2 in @modelcontextprotocol/express, and from 2.0.0 until 2.3.1 in @modelcontextprotocol/server-legacy, server-side bearer authentication could accept a valid access token issued for a different service because the SDK did not enforce the token audience. The affected surface is server-side HTTP bearer authentication. The trigger is a valid token whose audience names another service. The authorization server must issue tokens for multiple services, and the application's verifyAccessToken() must not independently validate aud. Applications already validating aud inside verifyAccessToken() are not affected. An attacker with a token for another service could authenticate to the MCP server and obtain the confidentiality and integrity capabilities granted to an authenticated caller. Upgrading alone leaves the new audience validation disabled. Operators must enable audience validation and provide the token audience together. Enabling only the expected audience check causes every request to receive HTTP 401. This issue is fixed in @modelcontextprotocol/sdk 1.32.0, @modelcontextprotocol/server 2.3.0, @modelcontextprotocol/express 2.0.2, and @modelcontextprotocol/server-legacy 2.3.1.","status":"published","published":"2026-11-05T21:18:35.973Z","modified":"2026-11-10T05:17:42.073Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N","level":"medium","assessor":"secondary"}],"cwes":["CWE-863"],"updated_at":"2026-11-10T07:18:23.535277Z"}],"osv":[{"id":"CVE-2026-111771","title":"Model Context Protocol TypeScript SDK: Server bearer authentication accepted tokens issued for another service","description":"The Model Context Protocol TypeScript SDK provides TypeScript client and server implementations of the Model Context Protocol. From 1.6.0 until 1.32.0 in @modelcontextprotocol/sdk, from 2.0.0 until 2.3.0 in @modelcontextprotocol/server, from 2.0.0 until 2.0.2 in @modelcontextprotocol/express, and from 2.0.0 until 2.3.1 in @modelcontextprotocol/server-legacy, server-side bearer authentication could accept a valid access token issued for a different service because the SDK did not enforce the token audience. The affected surface is server-side HTTP bearer authentication. The trigger is a valid token whose audience names another service. The authorization server must issue tokens for multiple services, and the application's verifyAccessToken() must not independently validate aud. Applications already validating aud inside verifyAccessToken() are not affected. An attacker with a token for another service could authenticate to the MCP server and obtain the confidentiality and integrity capabilities granted to an authenticated caller. Upgrading alone leaves the new audience validation disabled. Operators must enable audience validation and provide the token audience together. Enabling only the expected audience check causes every request to receive HTTP 401. This issue is fixed in @modelcontextprotocol/sdk 1.32.0, @modelcontextprotocol/server 2.3.0, @modelcontextprotocol/express 2.0.2, and @modelcontextprotocol/server-legacy 2.3.1.","status":"published","published":"2026-11-05T21:08:55.758Z","modified":"2026-11-11T02:30:26.309269835Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N","level":"medium"}],"cwes":["CWE-863"],"updated_at":"2026-11-07T03:08:00.544003Z"},{"id":"GHSA-rvq5-wwqv-78pq","title":"MCP TypeScript SDK: Server bearer authentication accepted tokens issued for another service","description":"### Summary\nIn affected versions, the SDK's server-side bearer authentication had no way to check that a token was issued for your server (its audience). Where one authorization server issues tokens for several services, a valid token for another service was also accepted by your MCP server.\n\n### Am I affected?\nYes, if your HTTP server uses `requireBearerAuth()` or `verifyBearerToken()`, its authorization server also issues tokens for other services, and your `verifyAccessToken()` does not check the token's audience (`aud`) itself.\n\nAffected versions:\n\n- `@modelcontextprotocol/sdk` 1.6.0 through 1.31.0\n- `@modelcontextprotocol/server` 2.0.0 through 2.2.0\n- `@modelcontextprotocol/express` 2.0.0 through 2.0.1\n- `@modelcontextprotocol/server-legacy` 2.0.0 through 2.3.0\n\n### Fix\nUpgrade to:\n\n- 1.x: `@modelcontextprotocol/sdk` 1.32.0 or later\n- 2.x: `@modelcontextprotocol/server` 2.3.0 or later, together with `@modelcontextprotocol/express` 2.0.2 or later if you use it\n- `@modelcontextprotocol/server-legacy` 2.3.1 or later\n\n**Upgrading alone changes nothing.** The patched versions add an `expectedResource` setting that is off by default. To turn the check on, make both of these changes together:\n\n1. Pass the audience your authorization server puts in tokens for your server: `requireBearerAuth({ verifier, expectedResource: new URL('https://mcp.example.com/mcp') })`.\n2. Return the token's audience from `verifyAccessToken()` as `AuthInfo.resource`, also a `URL`.\n\nA token for another service then gets `401`. With only the first change, every request gets `401`.\n\nIf you cannot upgrade yet, reject any token whose `aud` does not include your server inside `verifyAccessToken()`. That closes the issue on every version.","status":"published","published":"2026-10-20T19:43:36Z","modified":"2026-10-20T20:00:04.595309934Z","cvss":[{"version":"3.1","score":6.8,"vector":"CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N","level":"medium"}],"cwes":["CWE-863"],"updated_at":"2026-11-02T15:46:56.281047Z"},{"id":"CLSA-2026-1793100011","title":"TuxCare security update for @modelcontextprotocol/sdk (3 CVEs)","description":"TuxCare rebuilt @modelcontextprotocol/sdk to address 3 CVEs. Fixed in 1.30.0-tuxcare.2.","status":"published","published":"2026-10-27T11:20:11Z","modified":"2026-10-27T13:30:13.922723781Z","updated_at":"2026-11-02T15:43:55.34846Z"},{"id":"CLSA-2026-1793110244","title":"TuxCare security update for @modelcontextprotocol/sdk (1 CVE)","description":"TuxCare rebuilt @modelcontextprotocol/sdk to address 1 CVE. Fixed in 1.29.0-tuxcare.4.","status":"published","published":"2026-10-27T14:10:44Z","modified":"2026-10-27T19:30:03.971377562Z","updated_at":"2026-11-02T15:43:55.34846Z"},{"id":"CLSA-2026-1793112043","title":"TuxCare security update for @modelcontextprotocol/sdk (4 CVEs)","description":"TuxCare rebuilt @modelcontextprotocol/sdk to address 4 CVEs. Fixed in 1.25.2-tuxcare.4.","status":"published","published":"2026-10-27T14:40:43Z","modified":"2026-10-30T19:46:05.142474665Z","updated_at":"2026-11-02T15:43:55.34846Z"},{"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-1793113170","title":"TuxCare security update for @modelcontextprotocol/sdk (4 CVEs)","description":"TuxCare rebuilt @modelcontextprotocol/sdk to address 4 CVEs. Fixed in 1.24.0-tuxcare.4.","status":"published","published":"2026-10-27T14:59:30Z","modified":"2026-10-30T19:46:06.482679292Z","updated_at":"2026-11-02T15:43:55.34846Z"},{"id":"CLSA-2026-1793887845","title":"TuxCare security update for @modelcontextprotocol/sdk (1 CVE)","description":"TuxCare rebuilt @modelcontextprotocol/sdk to address 1 CVE. Fixed in 1.26.0-tuxcare.4.","status":"published","published":"2026-11-05T15:10:45Z","modified":"2026-11-06T13:15:17.600639389Z","updated_at":"2026-11-06T13:44:09.891978Z"},{"id":"CLSA-2026-1793887992","title":"TuxCare security update for @modelcontextprotocol/sdk (2 CVEs)","description":"TuxCare rebuilt @modelcontextprotocol/sdk to address 2 CVEs. Fixed in 1.30.1-tuxcare.3.","status":"published","published":"2026-11-05T15:13:13Z","modified":"2026-11-06T13:15:18.562249862Z","updated_at":"2026-11-06T13:44:09.891978Z"},{"id":"CLSA-2026-1793887996","title":"TuxCare security update for @modelcontextprotocol/sdk (3 CVEs)","description":"TuxCare rebuilt @modelcontextprotocol/sdk to address 3 CVEs. Fixed in 1.17.3-tuxcare.4.","status":"published","published":"2026-11-05T15:13:17Z","modified":"2026-11-06T13:15:16.797880742Z","updated_at":"2026-11-06T13:44:09.891978Z"}]}}