
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: >= 2.0.0, < 2.2.0
Patched in 2.2.0
Vulnerable: >= 1.10.0, < 1.30.0
Patched in 1.30.0
Details
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.
Yes, 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.
Affected versions:
mcp 1.10.0 through 1.29.1mcp 2.0.0 through 2.1.1Upgrade to:
mcp 1.30.0 or latermcp 2.2.0 or laterUpgrading 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:
validate_token_resource=True in AuthSettings, with resource_server_url set to the audience your authorization server puts in tokens for your server.verify_token() 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 validate_token_resource=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 verify_token(). That closes the issue on every version.
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.