{"id":"CVE-2026-116684","aliases":["EUVD-2026-111369","GHSA-w4fh-qvv9-3v23"],"status":"published","title":"Model Context Protocol Python SDK: Server bearer-token authentication accepts tokens issued for a different resource server","description":"The Model Context Protocol Python SDK is the official Python SDK for Model Context Protocol servers and clients. From 1.10.0 until 1.30.0 and 2.2.0, server-side bearer authentication configured through AuthSettings with token_verifier accepts a valid token issued for another service when the authorization server serves multiple resources and the TokenVerifier does not independently validate the aud audience. This resource-confusion flaw lets a token holder authenticate to the wrong MCP server and exercise that token's resulting access. This issue is fixed in versions 1.30.0 and 2.2.0.","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.00365,"percentile":0.3078,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-863"],"published":"2026-10-27T19:12:24Z","modified":"2026-11-04T02:30:47Z","fixes":[{"ecosystem":"PyPI","package":"mcp","fixed_in":["2.2.0","1.30.0"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"PyPI","package":"mcp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.0.0"},{"fixed":"2.2.0"}]}]},{"source":"ghsa","ecosystem":"PyPI","package":"mcp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.10.0"},{"fixed":"1.30.0"}]}]},{"source":"osv","ecosystem":"PyPI","package":"mcp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.0.0"},{"fixed":"2.2.0"}]}],"versions":["2.0.0","2.0.1","2.1.0","2.1.1"]},{"source":"osv","ecosystem":"PyPI","package":"mcp","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"1.10.0"},{"fixed":"1.30.0"}]}],"versions":["1.10.0","1.10.1","1.11.0","1.12.0","1.12.1","1.12.2","1.12.3","1.12.4","1.13.0","1.13.1","1.14.0","1.14.1","1.15.0","1.16.0","1.17.0","1.18.0","1.19.0","1.20.0","1.21.0","1.21.1","1.21.2","1.22.0","1.23.0","1.23.1","1.23.2","1.23.3","1.24.0","1.25.0","1.26.0","1.27.0","1.27.1","1.27.2","1.28.0","1.28.1","1.29.0","1.29.1"]}],"products":[{"vendor":"modelcontextprotocol","product":"python-sdk"}],"references":[{"url":"https://github.com/modelcontextprotocol/python-sdk/security/advisories/GHSA-w4fh-qvv9-3v23","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/modelcontextprotocol/python-sdk/pull/3447","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/modelcontextprotocol/python-sdk/pull/3451","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/modelcontextprotocol/python-sdk/commit/0c9136841ff092987a20700ff9c2c9789bda2f40","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/modelcontextprotocol/python-sdk/commit/8c2fa6eabacde869d75568e33b9d466b58c2f512","tags":["x_refsource_MISC","fix","web"]},{"url":"https://github.com/modelcontextprotocol/python-sdk/releases/tag/v1.30.0","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/modelcontextprotocol/python-sdk/releases/tag/v2.2.0","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/advisories/GHSA-w4fh-qvv9-3v23"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/116xxx/CVE-2026-116684.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-116684","tags":["advisory"]},{"url":"https://github.com/modelcontextprotocol/python-sdk","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-116684","title":"Model Context Protocol Python SDK: Server bearer-token authentication accepts tokens issued for a different resource server","description":"The Model Context Protocol Python SDK is the official Python SDK for Model Context Protocol servers and clients. From 1.10.0 until 1.30.0 and 2.2.0, server-side bearer authentication configured through AuthSettings with token_verifier accepts a valid token issued for another service when the authorization server serves multiple resources and the TokenVerifier does not independently validate the aud audience. This resource-confusion flaw lets a token holder authenticate to the wrong MCP server and exercise that token's resulting access. This issue is fixed in versions 1.30.0 and 2.2.0.","status":"published","published":"2026-10-27T19:12:24.255Z","modified":"2026-11-02T19:40:02.808Z","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-02T20:51:24.336573Z"}],"euvd":[{"id":"EUVD-2026-111369","description":"The Model Context Protocol Python SDK is the official Python SDK for Model Context Protocol servers and clients. From 1.10.0 until 1.30.0 and 2.2.0, server-side bearer authentication configured through AuthSettings with token_verifier accepts a valid token issued for another service when the authorization server serves multiple resources and the TokenVerifier does not independently validate the aud audience. This resource-confusion flaw lets a token holder authenticate to the wrong MCP server and exercise that token's resulting access. This issue is fixed in versions 1.30.0 and 2.2.0.","status":"published","published":"2026-10-27T19:12:24Z","modified":"2026-11-02T19:40:02Z","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-03T05:08:38.228652Z"}],"ghsa":[{"id":"GHSA-w4fh-qvv9-3v23","title":"Model Context Protocol Python SDK: Server bearer-token authentication accepts tokens issued for a different resource server","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 the SDK's bearer authentication (`auth=AuthSettings(...)` with `token_verifier=`), its authorization server also issues tokens for other services, and your `TokenVerifier` does not check the token's audience (`aud`) itself.\n\nAffected versions:\n\n- `mcp` 1.10.0 through 1.29.1\n- `mcp` 2.0.0 through 2.1.1\n\n### Fix\nUpgrade to:\n\n- 1.x: `mcp` 1.30.0 or later\n- 2.x: `mcp` 2.2.0 or later\n\n**Upgrading alone changes nothing.** The patched versions add a `validate_token_resource` setting that is off unless you set it. To turn the check on, make both of these changes together:\n\n1. Set `validate_token_resource=True` in `AuthSettings`, with `resource_server_url` set to the audience your authorization server puts in tokens for your server.\n2. Return the token's audience from `verify_token()` as `AccessToken.resource`.\n\nA token for another service then gets `401`. With only the first change, every request gets `401`.\n\nIf your `TokenVerifier` already checks the audience, set `validate_token_resource=False` to silence the deprecation warning. The setting will default to `True` in 3.0.\n\nIf you cannot upgrade yet, reject any token whose `aud` does not include your server inside `verify_token()`. That closes the issue on every version.","status":"published","published":"2026-10-27T21:06:59Z","modified":"2026-10-27T21:07:01Z","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:38.969831Z"}],"nvd":[{"id":"CVE-2026-116684","description":"The Model Context Protocol Python SDK is the official Python SDK for Model Context Protocol servers and clients. From 1.10.0 until 1.30.0 and 2.2.0, server-side bearer authentication configured through AuthSettings with token_verifier accepts a valid token issued for another service when the authorization server serves multiple resources and the TokenVerifier does not independently validate the aud audience. This resource-confusion flaw lets a token holder authenticate to the wrong MCP server and exercise that token's resulting access. This issue is fixed in versions 1.30.0 and 2.2.0.","status":"published","published":"2026-10-27T20:17:13.307Z","modified":"2026-11-02T20:17:32.943Z","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-03T00:02:37.938656Z"}],"osv":[{"id":"CVE-2026-116684","title":"Model Context Protocol Python SDK: Server bearer-token authentication accepts tokens issued for a different resource server","description":"The Model Context Protocol Python SDK is the official Python SDK for Model Context Protocol servers and clients. From 1.10.0 until 1.30.0 and 2.2.0, server-side bearer authentication configured through AuthSettings with token_verifier accepts a valid token issued for another service when the authorization server serves multiple resources and the TokenVerifier does not independently validate the aud audience. This resource-confusion flaw lets a token holder authenticate to the wrong MCP server and exercise that token's resulting access. This issue is fixed in versions 1.30.0 and 2.2.0.","status":"published","published":"2026-10-27T19:12:24.255Z","modified":"2026-11-04T02:30:47.964957457Z","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-04T02:54:44.889498Z"},{"id":"GHSA-w4fh-qvv9-3v23","title":"Model Context Protocol Python SDK: Server bearer-token authentication accepts tokens issued for a different resource server","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 the SDK's bearer authentication (`auth=AuthSettings(...)` with `token_verifier=`), its authorization server also issues tokens for other services, and your `TokenVerifier` does not check the token's audience (`aud`) itself.\n\nAffected versions:\n\n- `mcp` 1.10.0 through 1.29.1\n- `mcp` 2.0.0 through 2.1.1\n\n### Fix\nUpgrade to:\n\n- 1.x: `mcp` 1.30.0 or later\n- 2.x: `mcp` 2.2.0 or later\n\n**Upgrading alone changes nothing.** The patched versions add a `validate_token_resource` setting that is off unless you set it. To turn the check on, make both of these changes together:\n\n1. Set `validate_token_resource=True` in `AuthSettings`, with `resource_server_url` set to the audience your authorization server puts in tokens for your server.\n2. Return the token's audience from `verify_token()` as `AccessToken.resource`.\n\nA token for another service then gets `401`. With only the first change, every request gets `401`.\n\nIf your `TokenVerifier` already checks the audience, set `validate_token_resource=False` to silence the deprecation warning. The setting will default to `True` in 3.0.\n\nIf you cannot upgrade yet, reject any token whose `aud` does not include your server inside `verify_token()`. That closes the issue on every version.","status":"published","published":"2026-10-27T21:06:59Z","modified":"2026-10-27T21:15:03.825987077Z","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:58.04805Z"}]}}