CVE-2026-111771

MCP bearer authentication can accept another service’s token

Model Context Protocol maintainers · MCP TypeScript server bearer authentication

First documented disclosure · Review checkpoint

Summary

A valid token for a different service can pass the MCP server’s bearer check.

Severity and exploitation evidence

Medium · 6.8/10 · CVSS 3.1. Severity source.

Exploitation not established: The advisory and patch explain the authorization defect; malicious exploitation is not established.

Exploitation evidence source

Technical severity is not a measure of observed attacks or of risk to your deployment. Attempts, demonstrations, and successful compromise retain the qualifications in the source.

How the weakness works

The helper does not require an audience matching this resource unless the application enforces it.

Conditions required

A shared authorization server issues tokens for several services; the caller has another service’s valid token; verifyAccessToken does not check audience.

Potential impact

Unauthorized access using a token not intended for this MCP resource.

Affected versions and configurations

SDK 1.6.0–1.31.0; server 2.0.0–2.2.0; express 2.0.0–2.0.1; server-legacy 2.0.0–2.3.0.

Fix and mitigation status

SDK 1.32.0, server 2.3.0, express 2.0.2 and server-legacy 2.3.1 add an optional check, disabled by default.

Practical next steps

Upgrade the applicable packages, set expectedResource and return the verified audience as AuthInfo.resource. Alternatively reject the wrong audience inside the verifier.

Operating lesson

Verify who a token was issued to, not merely who issued it.

Evidence and limits

Public changes started October 2; legacy support and the advisory followed October 5; the CVE was published November 5. Upgrading alone does not enforce audience. Setting only expectedResource without returning resource rejects every token.

Sources