CVE-2026-111771 · GHSA-rvq5-wwqv-78pq

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

Risk score: 46/100
CVSS: 6.8 v3.1
Published: 20 Oct 2026

Open in the live forecast Today's forecast

What to know

What it is: 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. Yes, if your HTTP server uses requireB…
Affected: @modelcontextprotocol/sdk (npm) >= 1.6.0, < 1.32.0; @modelcontextprotocol/server (npm) >= 2.0.0, < 2.3.0; @modelcontextprotocol/express (npm) >= 2.0.0, < 2.0.2; @modelcontextprotocol/server-legacy (npm) >= 2.0.0, < 2.3.1
Fix: Upgrade @modelcontextprotocol/sdk to 1.32.0; @modelcontextprotocol/server to 2.3.0; @modelcontextprotocol/express to 2.0.2; @modelcontextprotocol/server-legacy to 2.3.1 or later.
Exploitation: No known exploitation

Story map

Story map: the flaws, the fix, how it unfolded and what it connects to. Boxes link to the record or article.

At a glance

@modelcontextprotocol/sdk: Amber, patch this week. The MCP TypeScript SDK's experimental tasks feature did not check which session created a task, allowing clients to list, read, and cancel each other's tasks. An attacker could exploit this vulnerability to gain control over other clients' tasks.

The flaws

CVE-2026-111771: MCP TypeScript SDK: Server bearer authentication accepted tokens issued for another service (CVSS 6.8)
CVE-2026-111767: MCP TypeScript SDK: Experimental tasks were not tied to the session that created them (CVSS 8.6 · EPSS 0%)
CVE-2026-104850: MCP TypeScript SDK: OAuth client could send credentials to an authorization server chosen by the MCP server (CVSS 7.5 · EPSS 0%)
CVE-2026-111768: MCP TypeScript SDK: One HTTP request within the default size limit could exhaust server memory during validation (CVSS 7.5)

The fix

Upgrade @modelcontextprotocol/sdk: 1.32.0 · 1.31.0 · 2.2.0 or later on your release line

Who is exposed: {'products': ['MCP TypeScript SDK'], 'packages': [{'ecosystem': 'npm', 'name': '@modelcontextprotocol/sdk', 'vulnerable': '>= 1.24.0, < 1.32.0', 'patched': '1.32.0'}], 'versions': ['1.24.0 to 1.32.0 (exclusive)', '1.32.0']}

Where it stands

No known exploitation

Connects to

Same weakness: Incorrect authorisation (CWE-863). 335 other warnings in 30 days

Why it is Yellow

CVSS 6.8 medium
On your watchlist: npm

Affected packages

Package	Ecosystem	Vulnerable	Fixed in
@modelcontextprotocol/sdk	npm	>= 1.6.0, < 1.32.0	1.32.0
@modelcontextprotocol/server	npm	>= 2.0.0, < 2.3.0	2.3.0
@modelcontextprotocol/express	npm	>= 2.0.0, < 2.0.2	2.0.2
@modelcontextprotocol/server-legacy	npm	>= 2.0.0, < 2.3.1	2.3.1

References

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

Last activity 20 Oct 2026. Patch Forecast updates every hour.