CVE-2026-116684: Model Context Protocol Python SDK: Server bearer-token authentication accepts tokens issued for a different resource server
Summary In 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.
Am I affected? Yes, if your HTTP server uses the SDK's bearer authentication (auth=AuthSettings(...) with tokenverifier=), its authorization server also issues tokens for other services, and your TokenVerifier does not check the token's audience (aud) itself.
Affected versions:
- mcp 1.10.0 through 1.29.1 - mcp 2.0.0 through 2.1.1
Fix Upgrade to:
- 1.x: mcp 1.30.0 or later - 2.x: mcp 2.2.0 or later
Upgrading alone changes nothing. The patched versions add a validatetokenresource setting that is off unless you set it. To turn the check on, make both of these changes together:
1. Set validatetokenresource=True in AuthSettings, with resourceserverurl set to the audience your authorization server puts in tokens for your server. 2. Return the token's audience from verifytoken() as AccessToken.resource.
A token for another service then gets 401. With only the first change, every request gets 401.
If your TokenVerifier already checks the audience, set validatetokenresource=False to silence the deprecation warning. The setting will default to True in 3.0.
If you cannot upgrade yet, reject any token whose aud does not include your server inside verifytoken(). That closes the issue on every version.
Other sources
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 tokenverifier 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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/mcpto a version that resolves this vulnerability.Fixed in 1.30.0 - Upgrade
Upgrade
pip/mcpto a version that resolves this vulnerability.Fixed in 2.2.0 - Upgrade
Upgrade
Model Context Protocol Python SDKto a version that resolves this vulnerability.Fixed in 1.30.0 - Upgrade
Upgrade
Model Context Protocol Python SDKto a version that resolves this vulnerability.Fixed in 2.2.0 - Configuration
Set validate_token_resource=True in AuthSettings and set resource_server_url to the audience that the authorization server places in tokens for this server.
Model Context Protocol Python SDK validate_token_resource = True - Configuration
Return the token's audience from verify_token() as AccessToken.resource.
Model Context Protocol Python SDK AccessToken.resource = token audience - Configuration
If TokenVerifier already independently checks the audience, set validate_token_resource=False to silence the deprecation warning.
Model Context Protocol Python SDK validate_token_resource = False - Compensating control
If you cannot upgrade, reject any token whose aud does not include your server inside verify_token().
Event History
Frequently Asked Questions
Which deployments are exposed?
Servers using AuthSettings with a token_verifier are affected when their authorization server issues tokens for multiple resources and the TokenVerifier does not independently validate the token's aud audience.
What does an attacker need to exploit this?
The attacker needs a valid bearer token issued for a different resource server by the same authorization server. They can then use that token to authenticate to the wrong MCP server and obtain the access associated with it.
What can be done if upgrading is not immediately possible?
Ensure the TokenVerifier independently validates the aud audience so that only tokens issued for the intended resource server are accepted.
Which releases contain the fix?
The issue is fixed in versions 1.30.0 and 2.2.0.