Live › vulnerability › CVE-2026-116684
Go to dashboardThe official Model Context Protocol Python SDK's bearer authentication accepts a valid token issued for a different service when the token verifier does not check the aud audience claim. A token holder can authenticate to the wrong MCP server and use the access that token grants there.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-27 20:33 UTC. All times on this page are UTC.
Teams running an MCP server built on the Python SDK with AuthSettings and a custom token_verifier that accepts bearer tokens, especially where the authorization server issues tokens for multiple resources. Servers that do not use bearer authentication through this path, or that already validate aud in their verifier, are not exposed by this flaw.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| mcp | pypi | >= 2.0.0, < 2.2.0 | 2.2.0 |
| mcp | pypi | >= 1.10.0, < 1.30.0 | 1.30.0 |
pip show mcp and look for versions from 1.10.0 up to before 1.30.0, or 2.0.0 through 2.1.x.AuthSettings and token_verifier and confirm the verifier validates the aud claim.mcp Python package to 1.30.0 or 2.2.0, matching your major version.token_verifier validate that the token's aud claim matches this MCP server.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
This page as .md · .json · in your agent: get_signal("CVE-2026-116684")
NVD data is provided by NIST and is public domain · GitHub Advisory Database, CC-BY 4.0. Posts quoted belong to their authors.