Vulnerability high
CVSS
high
7.7/10

CVE-2026-109527: MCP Reference SDKs: A Shared Server Instance Delivered One HTTP Client's Messages to Another, Bearer Auth Accepted Tokens Issued for Other Services, and Unbounded Requests Could Exhaust Memory

CVE-2026-109527 is a high-severity authentication bypass issue (CVSS 7.7) in @modelcontextprotocol/sdk, a MCP server. Affected: >=1.3.0 <1.32.0. Fixed in 1.32.0.

Is @modelcontextprotocol/sdk running on your developers' machines? Anomity finds every device with this MCP server installed, shows the version, and can block it by policy. Detect this across your developers' devices with Anomity →

Key facts

ID
CVE-2026-109527
Aliases
GHSA-jm63-cq47-j5jp
Severity
high
CVSS score
7.7
Attack type
Authentication bypass, Information disclosure
Component
@modelcontextprotocol/sdk · MCP server
Package
@modelcontextprotocol/sdk npm
Known exploited
No known exploitation
Published
Last verified

What is CVE-2026-109527?

The Model Context Protocol maintainers published another batch of server-side SDK advisories between 30 September and 15 October 2026. GHSA-jm63-cq47-j5jp (TypeScript, 15 October, CVSS 7.7): @modelcontextprotocol/server 2.0.0 to 2.2.0 matched messages to a connection by JSON-RPC id alone, and SDK clients number requests from 0, so ids collide in normal use. Where one stateless transport or one McpServer was shared across HTTP clients, a pattern the hono, express, fastify and node README examples showed until this release, one client could receive another client's responses and notifications. GHSA-rvq5-wwqv-78pq (TypeScript) and GHSA-w4fh-qvv9-3v23 (Python), both published 5 October and rated medium (CVSS 6.8): server-side bearer authentication could not check a token's audience, so where one authorization server issues tokens for several services, a token issued for another service was accepted. The patched versions add an audience check (expectedResource, validate_token_resource) that stays off until you configure it. Denial of service, all CVSS 7.5 and none needing credentials unless the application authenticates first: TypeScript GHSA-f897-62hf-6gxq (no request-body or JSON-RPC batch limit, fixed in sdk 1.30.1), TypeScript GHSA-46jr-4wx8-v453 (one request under the 4 MiB limit could exhaust memory during validation, fixed in sdk 1.32.0 with an opt-in maxToolInputElements), Python CVE-2026-109527 (request bodies read with no limit, fixed in 1.29.1 and 2.1.0) and Python CVE-2026-59951 (stateful Streamable HTTP sessions never reclaimed, fixed in 1.30.0 and 2.2.0). Servers that use only stdio are not affected. These are separate from the OAuth client issues in earlier entries.

Affected versions

AffectedFixed in
>=1.3.0 <1.32.01.32.0

Am I affected by CVE-2026-109527?

You are affected if you run @modelcontextprotocol/sdk >=1.3.0 <1.32.0. Versions 1.32.0 and later include the fix.

How do I fix CVE-2026-109527?

Upgrade @modelcontextprotocol/sdk to 1.32.0 or later, @modelcontextprotocol/server to 2.3.0 or later (with @modelcontextprotocol/express 2.0.2, @modelcontextprotocol/node 2.1.0, @modelcontextprotocol/hono 2.0.1 and @modelcontextprotocol/server-legacy 2.3.1 where used), and the Python mcp package to 1.30.0 or 2.2.0. Then make the code changes the upgrade does not make for you: build a new McpServer and transport per request or per session rather than once at startup; turn on the audience check (expectedResource in TypeScript, validate_token_resource=True with resource_server_url in Python) and return the token audience from your verifier, or check aud yourself; and set maxToolInputElements and a maxRequestBodySize that fit your tools. Cap request body size in a reverse proxy in front of any internet-reachable MCP server.

How do I find every machine running @modelcontextprotocol/sdk?

Anomity inventories the AI agents, MCP servers, IDE extensions and skills on each developer device, so you can see which machines run @modelcontextprotocol/sdk and which version, then enforce a policy on it.

References