CVE-2026-116684 in python-sdk
Summary
by MITRE • 10/27/2026
The Model Context Protocol Python SDK is the official Python SDK for Model Context Protocol servers and clients. From 1.10.0 until 1.30.0 and 2.2.0, server-side bearer authentication configured through AuthSettings with token_verifier accepts a valid token issued for another service when the authorization server serves multiple resources and the TokenVerifier does not independently validate the aud audience. This resource-confusion flaw lets a token holder authenticate to the wrong MCP server and exercise that token's resulting access. This issue is fixed in versions 1.30.0 and 2.2.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/27/2026
The Model Context Protocol Python SDK serves as the official software development kit for implementing servers and clients within the Model Context Protocol ecosystem, facilitating secure interactions between large language models and external tools or data sources. A critical security flaw was identified in versions ranging from 1.10.0 up to but not including 1.30.0, as well as in version 2.2.0 of this SDK. The vulnerability resides specifically within the server-side bearer authentication mechanism when configured via AuthSettings with a custom token verifier implementation. This flaw represents a classic resource confusion attack vector where the system fails to properly validate that an incoming authorization token is intended for the specific service receiving it, rather than accepting any validly signed token from the same identity provider regardless of its target audience claim.
The technical root cause lies in the insufficient validation logic within the TokenVerifier component during the authentication process. When a client presents a bearer token to authenticate with an MCP server, the server relies on the configured verifier to validate the signature and claims of that JWT or similar structured token. In vulnerable configurations, while the cryptographic integrity of the token is verified, the audience claim, typically denoted as aud in JSON Web Token standards, is not independently checked against the expected service identifier for the current MCP server instance. This oversight allows an attacker who possesses a valid access token issued by an authorization server to present that same token to any other MCP server within the same trust domain or federation. Because the signature remains valid and the expiration times are likely still active, the flawed verifier accepts the authentication request without raising an error regarding audience mismatch.
This vulnerability has significant operational implications for organizations deploying multiple Model Context Protocol servers under a single identity provider infrastructure. An attacker with access to a token intended for one specific service or application can leverage that credential to authenticate against other MCP servers in the environment. This effectively bypasses access control boundaries, allowing unauthorized entities to exercise permissions and privileges associated with the compromised token on systems where they should have no standing. The impact extends beyond simple unauthorized access; it enables lateral movement within the AI infrastructure, potentially leading to data exfiltration from connected tools or databases, manipulation of model outputs through injected prompts via tool calls, or denial of service by exhausting resources under a legitimate but misappropriated identity. Such scenarios undermine the fundamental security guarantees expected in multi-tenant or distributed LLM application architectures where strict isolation between services is required.
To mitigate this risk, organizations must immediately upgrade to patched versions of the Model Context Protocol Python SDK, specifically version 1.30.0 or later for the legacy branch and version 2.2.0 or later for the current release line. These updates enforce proper audience validation within the default token verification logic, ensuring that tokens are rejected if their aud claim does not match the expected service identifier. For environments utilizing custom TokenVerifier implementations, developers must manually audit their code to ensure explicit checks against the intended audience value before granting access. This aligns with industry best practices outlined in CWE-287 regarding improper authentication and CWE-345 concerning insufficient verification of data authenticity. Furthermore, this incident highlights the importance of adhering to OAuth 2.0 security guidelines which mandate strict audience validation for confidential clients and public clients alike to prevent token misuse across different resource servers. Implementing these fixes ensures that identity assertions are bound tightly to their intended recipients, preserving the integrity and confidentiality of AI-driven workflows.