MCP TypeScript SDK accepted OAuth tokens for the wrong resource without opt-in checks

The official MCP TypeScript SDK accepted OAuth bearer tokens intended for a different resource when an application omitted the optional expected-resource audience validator.

GHSA-rvq5-wwqv-78pq documents audience confusion and its validation guidance. Updating a library without configuring the validator does not establish that an application now enforces audience binding.

A syntactically valid OAuth bearer token is not sufficient authorization for a particular MCP resource. The official TypeScript SDK's bearer middleware accepted tokens signed by a recognized issuer even when an application omitted expected-resource audience validation, permitting tokens minted for a different service to be replayed where resource claims were not checked. The failure requires tokens issued within a relevant trust configuration; it does not mean arbitrary strings authenticate. This Case is distinct from other SDK implementations and from individual MCP applications that separately enforce audience. Updating a dependency is only part of remediation if the server must explicitly configure the resource indicator and validator.

A signed bearer token can be valid for one resource and still be unauthorized for the MCP server that receives it. The failure is not a broken cryptographic signature; it is a missing resource-audience comparison at the server boundary. Clients and servers must agree on the intended audience and reject tokens for different resources even when an issuer is trusted. The pack also contains separate local-RPC approval and AgentScope identity failures, but neither is evidence that this SDK issue was exploited in those systems.