AI and data stack advisories

Severe, 6 weeks606Projects324

606 severe, 6 weeks · 324 projects

MCP SDKsGHSA-rvq5-wwqv-78pq

MCP TypeScript SDK: Server bearer authentication accepted tokens issued for another service

MCP SDKs

CVE-2026-111771 · Published Oct 20, 2026

Medium6.8
Fix: upgrade to 1.32.0 or later
GitHub advisory

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...

Affected versions

PackageAffectedFixed in
@modelcontextprotocol/sdk
npm
>= 1.6.0, < 1.32.01.32.0
Details and references

### 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.

CVSS 3.1
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
Severity from
GitHub (reviewed advisory)
Weakness
CWE-863
Also known as
CVE-2026-111771

More MCP SDKs advisories

All MCP SDKs