The MCP spec says servers must check who a token was issued for. The official SDKs could not, and the fix is off by default.
Upgrading alone changes nothing, both advisories say. Teams running MCP servers behind a shared login system have a configuration change to make, and a version bump will not make it for them.
Photo: Connected spheres with lines on dark background. // GaaS News- The official MCP Python and TypeScript SDKs accepted bearer tokens issued for other services, under CVE-2026-116684 and CVE-2026-111771, each rated 6.8.
- The MCP specification says servers "MUST validate" a token's audience. The SDKs' built-in bearer authentication gave developers no way to do it.
- The fix is opt-in. "Upgrading alone changes nothing," both advisories say.
The Model Context Protocol specification is blunt about tokens: "MCP servers MUST validate that access tokens were issued specifically for them as the intended audience." Two advisories published this month show that the project's own software development kits gave developers no way to do that. According to the Python advisory and its TypeScript counterpart, the SDKs' server-side bearer authentication "had no way to check that a token was issued for your server," so a valid token for another service "was also accepted by your MCP server."
The flaws are tracked as CVE-2026-116684 for Python and CVE-2026-111771 for TypeScript. Maintainers published both on October 5, and they reached the GitHub Advisory Database later in the month. The code shipped earlier: mcp 1.30.0 and 2.2.0 reached PyPI on September 7, and @modelcontextprotocol/sdk 1.32.0 reached npm on October 2.
Who the MCP token flaw affects
The MCP token flaw affects a specific setup, and both advisories spell it out. You are exposed if your HTTP server uses the SDK's bearer authentication, your authorization server also issues tokens for other services, and your token verifier does not check the audience claim itself. That is the arrangement you would expect at a company that puts an internal MCP server behind the same identity provider as everything else. A token minted for some other internal service would open the MCP server too.
Affected Python versions are mcp 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1. On TypeScript the list covers @modelcontextprotocol/sdk 1.6.0 through 1.31.0, @modelcontextprotocol/server 2.0.0 through 2.2.0, @modelcontextprotocol/express 2.0.0 through 2.0.1, and @modelcontextprotocol/server-legacy 2.0.0 through 2.3.0.
Why the MCP fix is off by default
The MCP fix is off by default, and both advisories use the same sentence to say so: "Upgrading alone changes nothing." The Python release adds a validate_token_resource setting "that is off unless you set it." The TypeScript release adds an expectedResource setting "that is off by default." Turning the Python check on means setting the flag, pointing resource_server_url at the audience your authorization server puts in its tokens, and returning that audience from verify_token(). Do only the first part and, the advisory warns, "every request gets 401."
That warning is the likely reason for the opt-in, though neither advisory says so: forcing the check on everyone would lock out servers whose verifiers do not yet return an audience. Python users get a deprecation warning in the meantime, and the setting "will default to True in 3.0." For anyone who cannot upgrade, the advisory offers a workaround that closes the issue on every version: reject any token whose aud claim does not include your server inside verify_token().
The MCP bearer token model carries the weight
The MCP bearer token model is why a moderate-rated bug deserves attention. A bearer token works for whoever holds it, so the audience claim is one of the few things limiting where a leaked or misdirected token can go. We reported in September on SEP-2752, a proposal to add signed requests that would tie each call to its sender. It still sits open without a sponsor, and the last maintainer word on the thread remains that "the working group has made a deliberate choice to standardize on OAuth." That choice puts the weight on implementations getting the OAuth details right, and this was one of those details.
What is not established
What is not established is how many servers fit all three conditions, and neither advisory reports exploitation. An attacker would already need a valid token from the same authorization server. Servers whose verifiers check the audience were never exposed. We did not test any deployment ourselves. NVD had no record for the TypeScript CVE when we looked this week.
What MCP server operators should do
MCP server operators should treat this as a configuration task with a short checklist:
- Find every server using the SDK's bearer authentication and check whether its authorization server also issues tokens for other services.
- Upgrade, then turn the check on: validate_token_resource in Python, expectedResource in TypeScript.
- Test with a token issued for another service and confirm you get a 401.
- If you run a gateway in front of MCP servers, enforce the audience there too.
Anyone still catching up on the protocol should read what changed in the 2026-07-28 spec, and our agent protocol explainer covers how MCP and A2A fit together.
