| パッケージ | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| @modelcontextprotocol/express | ≥ 2.0.0, < 2.0.2 | 2.0.2 |
| @modelcontextprotocol/sdk | ≥ 1.6.0, < 1.32.0 | 1.32.0 |
| @modelcontextprotocol/server | ≥ 2.0.0, < 2.3.0 | 2.3.0 |
| @modelcontextprotocol/server-legacy | ≥ 2.0.0, < 2.3.1 | 2.3.1 |
In affected versions, the SDK's server-side bearer authentication had no way to check that a token was issued for your server (its audience). Where one authorization server issues tokens for several services, a valid token for another service was also accepted by your MCP server.
Yes, if your HTTP server uses requireBearerAuth() or verifyBearerToken(), its authorization server also issues tokens for other services, and your verifyAccessToken() does not check the token's audience (aud) itself.
Affected versions:
@modelcontextprotocol/sdk 1.6.0 through 1.31.0@modelcontextprotocol/server 2.0.0 through 2.2.0@modelcontextprotocol/express 2.0.0 through 2.0.1@modelcontextprotocol/server-legacy 2.0.0 through 2.3.0Upgrade to:
@modelcontextprotocol/sdk 1.32.0 or later@modelcontextprotocol/server 2.3.0 or later, together with @modelcontextprotocol/express 2.0.2 or later if you use it@modelcontextprotocol/server-legacy 2.3.1 or laterUpgrading alone changes nothing. The patched versions add an expectedResource setting that is off by default. To turn the check on, make both of these changes together:
requireBearerAuth({ verifier, expectedResource: new URL('https://mcp.example.com/mcp') }).verifyAccessToken() as AuthInfo.resource, also a URL.A token for another service then gets 401. With only the first change, every request gets 401.
If you cannot upgrade yet, reject any token whose aud does not include your server inside verifyAccessToken(). That closes the issue on every version.
これらの製品をお使いですか?サイトをスキャンして、脆弱なバージョンが公開されていないか確認しましょう。
無料でサイトをスキャン