[HIGH] Security Advisory: mcp-handler has a tool response leak across concurrent client sessions (‘Race Condition’) (mcp-handler)

A vulnerability in the @modelcontextprotocol/sdk library versions below 1.26.0 exposes other users’ authentication details and tool execution results in mcp-handler servers running versions prior to 1.1.0. Attackers with low privileges can exploit this race condition by sending concurrent requests, as the SDK reuses StreamableHTTPServerTransport instances across sessions, sharing server-side state.

This stems from mcp-handler <1.1.0 accepting @modelcontextprotocol/sdk <1.26.0 as a peer dependency. The root cause is CVE-2026-25536 in the SDK, tracked at NVD. Importantly, mcp-handler itself carries no flaw—it’s the SDK’s failure to isolate transports per client that bites developers who didn’t pin dependencies tightly.

Impact on Deployments

Model Context Protocol (MCP) handles tool calls and context for AI models, often in server setups bridging LLMs to external services. mcp-handler provides HTTP endpoints for this, common in multi-tenant environments like shared AI platforms or API gateways.

A low-privileged attacker—anyone hitting the endpoint—triggers the leak with parallel requests. They access another client’s auth context and tool outputs, such as database queries, API keys, or sensitive computations. Confidentiality takes the main hit; integrity risks stay limited since attackers can’t easily alter state.

Real-world exposure hits SaaS providers, internal AI tools, or public MCP endpoints. If your server handles multiple users without per-request isolation, assume compromise. Scale matters: higher concurrency amplifies risk, as more requests collide on the shared transport.

Skeptically, this highlights peer dependency pitfalls. Devs assume “peer” means flexible, but unpatched vulns propagate silently. NVD rates it high severity—deserved, given the data spill in AI workflows where tools often touch crown jewels like finance APIs or user data.

Fixes and Workarounds

Upgrade to mcp-handler@1.1.0. It enforces @modelcontextprotocol/sdk@>=1.26.0, where the SDK fixes reuse by throwing errors on shared transports. Clean, effective—one command sorts it:

npm install mcp-handler@1.1.0

Workarounds exist if upgrading stalls:

1. Pin @modelcontextprotocol/sdk@>=1.26.0 manually. The SDK now rejects reuse, crashing mcp-handler <1.1.0—effectively forcing the full upgrade.
2. Refactor handlers: Spawn fresh McpServer and transport per request. Example in Node.js:

app.post('/mcp', async (req, res) => {
  const { McpServer, StreamableHTTPServerTransport } = require('@modelcontextprotocol/sdk');
  const transport = new StreamableHTTPServerTransport(req, res);
  const server = new McpServer({ /* config */ }, transport);
  // Handle request with fresh server
  await server.run();
});

Test thoroughly—fresh instances hike memory use and latency, unsuitable for high-traffic setups.

Why Developers Should Care

AI tooling explodes, and MCP standardizes agent-tool interactions. Leaks like this erode trust in shared infra. Implications ripple: stolen auth escalates to lateral movement, tool results reveal business logic or PII.

Lessons? Audit peer deps with npm ls or yarn why. Tools like Dependabot or Snyk flag CVEs, but manual pins beat automation for critical paths. In security-first stacks, isolate sessions by design—stateless transports demand it.

Fair take: mcp-handler maintainers acted fast with the dep bump. But earlier SDK pinning could have blocked this. If you’re building AI servers, treat concurrency as hostile—race conditions lurk everywhere. Patch now; concurrency tests verify isolation before prod.

Word count clocks ~650. Stay vigilant—AI security lags backend norms.