GHSA-w4fh-qvv9-3v23: Medium severity pip/mcp vulnerability
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.
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
mcpto a version that resolves this vulnerability.Fixed in 1.30.0 - Upgrade
Upgrade
mcpto 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 your server; return the token audience from verify_token() as AccessToken.resource.
MCP SDK bearer authentication validate_token_resource = True - Compensating control
If you cannot upgrade, reject any token whose aud does not include your server inside verify_token(). If TokenVerifier already checks the audience, set validate_token_resource=False to silence the deprecation warning.
Event History
Frequently Asked Questions
Which deployments require remediation?
Deployments are affected when their HTTP server uses bearer authentication through AuthSettings with token_verifier, the authorization server issues tokens for multiple services, and the TokenVerifier does not independently validate the token aud claim.
What would an attacker need to exploit this?
The attacker needs a valid token issued by the same authorization server for a different service. Without audience validation, the MCP server can accept that token as though it were intended for itself.
Does upgrading enable protection automatically?
No. In fixed releases, validate_token_resource is disabled unless explicitly enabled, so upgrading alone does not change token acceptance behavior.
What configuration is required after upgrading?
Set validate_token_resource=True in AuthSettings and set resource_server_url to the audience issued for the server. The verify_token() implementation must also return the token audience in AccessToken.resource; tokens for other services will then receive a 401 response.
Can a custom TokenVerifier already prevent the issue?
Yes. A deployment is not affected if its TokenVerifier already checks that the token audience matches the server.