CVE-2026-116684: MCP Python SDK 1.30.0 and 2.2.0 fix tokens for other services being accepted, client headers following cross-origin redirects, and clients fetching server-chosen schema URLs
Three advisories for the official MCP Python SDK (the mcp package) were published on 27 October 2026, fixed in mcp 1.30.0 and 2.2.0. Server bearer-token auth had no way to check a token's audience, so a token issued for another service was accepted. HTTP client transports sent custom headers, and on 307/308 the body, to whatever host a redirect pointed at. And clients fetched any $ref URL or local file a server put in a tool's output schema. The audience fix needs a config change, not just an upgrade.
What it is
CVE-2026-116684 (GHSA-w4fh-qvv9-3v23, servers, mcp 1.10.0 to 1.29.1 and 2.0.0 to 2.1.1): the SDK's bearer authentication (AuthSettings with token_verifier) could not check a token's aud claim, so where one authorization server issues tokens for several services, a valid token for another service also worked on your MCP server, unless your TokenVerifier checked the audience itself.
CVE-2026-116685 (GHSA-5h93-6whr-6q8j, clients, mcp 1.8.0 to 1.29.1 and 2.0.0 to 2.1.1): the Streamable HTTP and SSE client transports, and the OAuth providers' own discovery, registration and token requests, followed redirects to any host. Custom headers such as an X-API-Key were sent to the new origin, and on 307/308 the request body was re-sent there. A lone Authorization bearer header was not exposed.
CVE-2026-116686 (GHSA-rwrf-2pqf-9j8j, clients, mcp 1.10.0 to 1.29.1 and 2.0.0 to 2.1.1): when a server declared an outputSchema, the client validated tool results with jsonschema's default resolver, which opens any http://, https:// or file:// $ref. A malicious server could make the client request internal URLs or read local files on every call, and a slow target could freeze every session in the process because the fetch had no timeout.
How to check
- Affected: mcp (PyPI) before 1.30.0 on the 1.x line and before 2.2.0 on the 2.x line (exact starting versions differ per issue).
- Servers are affected by the audience issue if they use the SDK's bearer auth and their authorization server issues tokens for other services. Clients are affected by the other two if they connect over HTTP or call tools on servers you don't fully control.
How to fix
- Upgrade mcp to 1.30.0 or later (1.x) or 2.2.0 or later (2.x). The redirect and schema fixes need no code changes.
- For the audience fix, also set validate_token_resource=True in AuthSettings with resource_server_url set to your server's audience, and return the token's audience from verify_token() as AccessToken.resource. Upgrading alone changes nothing; setting only the flag makes every request return 401.
- Until you can upgrade, reject tokens whose aud doesn't include your server inside verify_token(), and only call tools on servers you trust.
pip show mcp | grep -i version
pip install -U 'mcp>=1.30.0' Sources
- criticalCVE-2026-114612: LiteLLM proxy lets an internal user forge an admin token and run commands
- criticalMalicious npm packages posing as AI agent tools: agentic-awesome-skills, x402-prompt-injection-scan and formatting-subtitles-for-claude
- criticalCVE-2026-114125: A malicious website can tamper with your project through a running Storybook dev server
- criticalCVE-2026-102503: Google Agent Mesh let any peer call MCP backends through an unchecked ingress