Key points
- The vulnerability allows one client's messages to reach another client using the same server instance.
- Affected versions include @modelcontextprotocol/server 2.0.0 through 2.2.0; version 2.3.0 fixes the issue.
- Upgrading requires code changes to prevent sharing server instances across multiple connections.
The @modelcontextprotocol/server package versions 2.0.0 through 2.2.0 contain a high-severity flaw that leaks client data. The issue affects applications that serve the Model Context Protocol over HTTP using a single server instance for multiple clients. A fix is available in version 2.3.0, but it requires developers to modify their application code to create new server instances for each connection or session.
In plain English
This flaw occurs when an MCP server runs over HTTP and handles multiple clients using one shared stateless transport or server object. The system identifies messages using only a JSON-RPC ID number. Because clients start numbering their requests from zero, these IDs often collide. When collisions happen, the server may deliver a response or notification intended for one client to a different client connected to the same endpoint.
The background
The GitHub advisory GHSA-jm63-cq47-j5jp identifies CVE-2026-111770 as the source of this exposure. The problem exists when code creates the transport or server once at startup, rather than per request or per session. Previous README examples for Hono, Express, Fastify, and Node.js demonstrated this vulnerable pattern. Versions 1.26.0 and later of the @modelcontextprotocol/sdk are not affected, nor are stdio servers or configurations using createMcpHandler with a factory function.
What changes now
Developers must upgrade to @modelcontextprotocol/server 2.3.0 or later to resolve the security flaw. The updated SDK refuses to be shared across connections, meaning affected apps will fail requests if they do not change their code. A second connect call will reject with ALREADY_CONNECTED, and stateless transports will reject subsequent requests. Teams must refactor code to build a new McpServer per request, per session, or via a factory function in createMcpHandler.
Who needs to act first
Teams should prioritize updating any HTTP-facing MCP servers that handle multiple clients simultaneously. Identify systems where a single server instance serves all incoming requests without session isolation. Test the code changes thoroughly in a staging environment before deploying to production, as the new SDK enforces stricter connection rules. Ensure backups are current before making changes, and verify that no legacy code paths still attempt to share server objects across different user sessions.
What to do and how to stay safe: @modelcontextprotocol/server
- Review your application code to see if it shares a single McpServer or transport instance across multiple HTTP requests.
- Upgrade to @modelcontextprotocol/server 2.3.0 or later once the vendor provides an update and you have validated the code changes.
- Refactor your server initialization to create a new server instance for each request or user session to prevent ID collisions.
- Monitor logs for unexpected connection errors or ALREADY_CONNECTED rejections after deploying the updated code to catch integration issues.
Step-by-step guide: Out-of-Band Patches: Meaning, Risks, and Deployment Reality
General security guidance from the Patch Herald newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which versions of the package are vulnerable?
Versions 2.0.0 through 2.2.0 of the @modelcontextprotocol/server package are affected by this high-severity flaw.
Is there a patch available?
Yes, version 2.3.0 of the @modelcontextprotocol/server package fixes the vulnerability, but it requires code changes to implement.
Are stdio servers affected by this issue?
No, stdio servers are not affected by this vulnerability, nor are versions 1.26.0 and later of the @modelcontextprotocol/sdk.
