CVE-2026-111771: Medium severity npm/@modelcontextprotocol/server-legacy vulnerability
Summary 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.
Am I affected? 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.0
Fix Upgrade to:
- 1.x: @modelcontextprotocol/sdk 1.32.0 or later - 2.x: @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 later
Upgrading 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:
1. Pass the audience your authorization server puts in tokens for your server: requireBearerAuth({ verifier, expectedResource: new URL('https://mcp.example.com/mcp') }). 2. Return the token's audience from 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/@modelcontextprotocol/server-legacyto a version that resolves this vulnerability.Fixed in 2.3.1 - Upgrade
Upgrade
npm/@modelcontextprotocol/expressto a version that resolves this vulnerability.Fixed in 2.0.2 - Upgrade
Upgrade
npm/@modelcontextprotocol/serverto a version that resolves this vulnerability.Fixed in 2.3.0 - Upgrade
Upgrade
npm/@modelcontextprotocol/sdkto a version that resolves this vulnerability.Fixed in 1.32.0 - Upgrade
Upgrade
@modelcontextprotocol/sdkto a version that resolves this vulnerability.Fixed in 1.32.0 - Upgrade
Upgrade
@modelcontextprotocol/serverto a version that resolves this vulnerability.Fixed in 2.3.0 - Upgrade
Upgrade
@modelcontextprotocol/expressto a version that resolves this vulnerability.Fixed in 2.0.2 - Configuration
Configure requireBearerAuth({ verifier, expectedResource: new URL('https://mcp.example.com/mcp') }) and return the token audience from verifyAccessToken() as AuthInfo.resource, also a URL; make both changes together.
MCP bearer authentication expectedResource = new URL('https://mcp.example.com/mcp') - Compensating control
If you cannot upgrade yet, reject any token whose aud does not include your server inside verifyAccessToken().
Event History
Frequently Asked Questions
Does upgrading automatically enforce audience validation?
No. The patched versions add an expectedResource setting, but it is off by default; upgrading alone does not change token-validation behavior.
What would an attacker need to exploit this?
They need a valid token issued by the same authorization server for a different service. The MCP server accepts that token when its verifyAccessToken() implementation does not independently validate the token's aud claim.