Model Context Protocol Python SDK: Server bearer-token authentication accepts tokens issued for a different resource server
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 1.30.0, 2.2.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
The Model Context Protocol Python SDK, used to build MCP servers and clients, is affected when its server-side bearer authentication relies on a custom token verifier that does not check the token's audience. As a result, a token issued for a different service can be accepted by an MCP server, letting its holder gain access to that server.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
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.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- modelcontextprotocol python-sdk
From 1.10.0 · fixed in 1.30.0; From 2.0.0 · fixed in 2.2.0
- mcpPyPI
From 2.0.0 · fixed in 2.2.0
- mcpPyPI
From 1.10.0 · fixed in 1.30.0