Open-Source Security Intelligence

Know every vulnerability
before it knows you.

DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.

Check if your repositories are affected!View on GitHub
Search

GHSA-rvq5-wwqv-78pq

MediumCVSS 6.8 / 10
Published Oct 20, 2026·Last modified Oct 20, 2026
Affected Components(4)
npm logo@modelcontextprotocol/sdk
1.6.0 – 1.32.0
npm logo@modelcontextprotocol/server-legacy
2.0.0 – 2.3.1
npm logo@modelcontextprotocol/server
2.0.0 – 2.3.0
1 / 2
Description

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.

Upload your SBOM

Upload your own SBOM in CycloneDX 1.6 or higher (JSON) directly here to check your vulnerabilities.

Risk Scores
Base Score
6.8

The vulnerability can be exploited over the network without needing physical access. It is difficult for an attacker to exploit this vulnerability and may require special conditions. An attacker needs basic access or low-level privileges. No user interaction is needed for the attacker to exploit this vulnerability. The impact is confined to the system where the vulnerability exists. There is a high impact on the confidentiality of the information. There is a high impact on the integrity of the data.

Threat Intelligence
6.2

Exploitation attempts have been detected. Elevated vigilance and prompt remediation are advised.

EPSS
N/A

Probability that this vulnerability will be exploited in the wild within the next 30 days.

Exploit
Not available

We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.

Related Vulnerabilities
  • CVE-2026-111771
    Alias

Browse More

Medium severity
Scan your project

Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.

Checkout DevGuard