MCP TypeScript SDK CVE-2026-111771

Exploitation requires a specific, documented combination: (1) the MCP HTTP server uses requireBearerAuth() or verifyBearerToken() from an affected SDK version (@modelcontextprotocol/sdk 1.6.0-1.31.0, @modelcontextprotocol/server 2.0.0-2.2.0, @modelcontextprotocol/express 2.0.0-2.0.1, or @modelcontextprotocol/server-legacy 2.0.0-2.3.0); (2) the same authorization server issues valid tokens for OTHER services besides this MCP server; and (3) the application's own verifyAccessToken() does not independently validate the token's 'aud' (audience) claim. Limiting factors that reduce real-world exposure: the attacker must already hold a valid token issued by that shared authorization server for a different service (PR:L), so this is not an unauthenticated bypass; environments using a dedicated single-audience authorization server, or whose verifyAccessToken() already checks 'aud', are not exploitable. Critically, the patched versions ship the 'expectedResource' audience check OFF by default - remediation requires both setting expectedResource on requireBearerAuth() and returning the token audience as AuthInfo.resource from verifyAccessToken(); upgrading alone changes nothing.

This is a moderate-severity authorization flaw (CWE-863, missing token audience validation) rated CVSS 6.8 with vector AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N. The signals are internally consistent and point to a real-but-conditional risk rather than a drop-everything emergency. The network vector (AV:N) and high confidentiality/integrity impact (C:H/I:H) are offset by two dampening metrics: AC:H reflects that exploitation depends on a specific deployment topology (one authorization server issuing tokens for multiple services AND the application not checking 'aud' itself), and PR:L reflects that the attacker must already possess a valid token legitimately issued for some other service by that shared authorization server - this is a confused-deputy/token-reuse condition, not an anonymous bypass. No EPSS score, no CISA KEV listing, and no public exploit were provided in the intelligence, so the exploitation status is 'no public exploit identified at time of analysis'; there is no evidence of active exploitation. The real priority is driven by the sensitivity of the data behind affected MCP servers and by how common the multi-service shared-authorization-server pattern is in a given environment, not by raw score. Note one nuance to verify: the patch is off by default (opt-in via 'expectedResource'), so merely upgrading does NOT remediate - this materially affects real-world residual risk and should be weighted in prioritization.

An organization runs several services (e.g., an MCP server and an unrelated API) that all accept bearer tokens from one shared OAuth authorization server, and the MCP server's verifyAccessToken() does not check the token's audience. An attacker who legitimately obtains a token scoped for the other, lower-value service replays that same token against the MCP server, which accepts it and grants access to MCP tools and data it was never authorized for. No public exploit code was identified; the attack is a straightforward token replay requiring no special tooling once a valid cross-service token is held.