Model Context Protocol Python SDK EUVD-2026-111369

All of the following must hold: the target runs the SDK's HTTP server-side bearer authentication (auth=AuthSettings(...) with token_verifier=); the authorization server it trusts also issues tokens for other services/resources; and the deployment's TokenVerifier does not itself validate the token's aud audience. The attacker must additionally already possess a valid bearer token issued by that same authorization server for a different service. Exploitation is LIMITED to affected versions (mcp 1.10.0-1.29.1 and 2.0.0-2.1.1) and does NOT apply when the authorization server serves only a single resource, when the TokenVerifier already checks aud, or after validate_token_resource=True is correctly configured with resource_server_url and AccessToken.resource - merely upgrading without that configuration does not enable the check.

This is a genuine but conditional authorization flaw (CWE-863, token audience/resource confusion), not a drop-everything emergency. The supplied CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N, base 6.8) is internally consistent with the mechanism: network-reachable, but gated by AC:H (a specific deployment - one authorization server issuing tokens for multiple resources plus a TokenVerifier that never checks aud) and PR:L (the attacker must already hold a valid token issued for some other service by that same authorization server). No EPSS score, no CISA KEV entry, and no public exploit were provided in the input, so there is no signal of active or widespread exploitation; the vuln.today Decision label is 'this_month' (not act_now/emergency). The realistic risk is therefore targeted lateral movement within a single-authorization-server, multi-resource environment rather than opportunistic mass exploitation - high technical impact (C:H/I:H) but narrowed by the required misconfiguration and prior token possession. No signals conflict here; the main caveat is that EPSS and POC status are simply absent from the input, not confirmed negative.

In an environment where one authorization server (for example an OAuth/OIDC provider) issues bearer tokens for several MCP servers and other services, an attacker who legitimately holds a token for service A presents that same token to a target MCP server B that uses the SDK's bearer auth without independently validating the token's aud. Because B never checks that the token was issued for it, the token is accepted and the attacker exercises whatever access that token grants against the wrong server. No public exploit code is identified in the input; the referenced PRs and commits are patch material, not a weaponized PoC.