GHSA-rvq5-wwqv-78pq: Medium severity npm/@modelcontextprotocol/server-legacy vulnerability

Published Oct 20, 2026
·
Updated

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

4 affected componentsFixes available
npm/@modelcontextprotocol/server-legacy>=2.0.0<2.3.1
2.3.1
npm/@modelcontextprotocol/express>=2.0.0<2.0.2
2.0.2
npm/@modelcontextprotocol/server>=2.0.0<2.3.0
2.3.0
npm/@modelcontextprotocol/sdk>=1.6.0<1.32.0
1.32.0

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/@modelcontextprotocol/server-legacy to a version that resolves this vulnerability.

    Fixed in 2.3.1
  2. Upgrade

    Upgrade npm/@modelcontextprotocol/express to a version that resolves this vulnerability.

    Fixed in 2.0.2
  3. Upgrade

    Upgrade npm/@modelcontextprotocol/server to a version that resolves this vulnerability.

    Fixed in 2.3.0
  4. Upgrade

    Upgrade npm/@modelcontextprotocol/sdk to a version that resolves this vulnerability.

    Fixed in 1.32.0
  5. Upgrade

    Upgrade @modelcontextprotocol/sdk to a version that resolves this vulnerability.

    Fixed in 1.32.0
  6. Upgrade

    Upgrade @modelcontextprotocol/server to a version that resolves this vulnerability.

    Fixed in 2.3.0
  7. Upgrade

    Upgrade @modelcontextprotocol/express to a version that resolves this vulnerability.

    Fixed in 2.0.2
  8. Configuration

    Pass the audience your authorization server puts in tokens for your server to requireBearerAuth({ verifier, expectedResource }) or the equivalent bearer-authentication configuration.

    MCP bearer authentication expectedResource = new URL('https://mcp.example.com/mcp')
  9. Configuration

    Return the token's audience from verifyAccessToken() as AuthInfo.resource, also a URL; make this change together with expectedResource.

    verifyAccessToken() AuthInfo.resource = the token's audience as a URL
  10. Compensating control

    If you cannot upgrade yet, reject any token whose aud does not include your server inside verifyAccessToken().

Event History

Oct 20, 2026
Advisory Published
via GitHub·07:43 PM
Data Sourced
via GitHub·07:43 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

What would an attacker need to exploit this issue?

The attacker needs a valid token issued by the same authorization server for a different service. If the MCP server does not validate the token's audience, it may accept that token as though it were intended for the MCP server.

2

Which deployments are exposed in practice?

Deployments are affected when their HTTP server uses requireBearerAuth() or verifyBearerToken(), the authorization server issues tokens for multiple services, and verifyAccessToken() does not independently validate the aud claim.

3

Is upgrading to a patched version sufficient to enable audience validation?

No. The patched versions add an expectedResource setting, but it is disabled by default; upgrading alone does not change token audience validation behavior.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203