chore(deps): update dependency @modelcontextprotocol/sdk to v1.26.0 [security]#2196
chore(deps): update dependency @modelcontextprotocol/sdk to v1.26.0 [security]#2196renovate[bot] wants to merge 1 commit intomainfrom
Conversation
|
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
Merging this PR will improve performance by 5.25%
Performance Changes
Comparing Footnotes
|
Web Explorer#7715 Bundle Size — 383.74KiB (0%).537e52c(current) vs 7e27895 main#7709(baseline) Bundle metrics
Bundle size by type
|
| Current #7715 |
Baseline #7709 |
|
|---|---|---|
252.83KiB |
252.83KiB |
|
95.85KiB |
95.85KiB |
|
35.06KiB |
35.06KiB |
Bundle analysis report Branch renovate/npm-modelcontextprotoco... Project dashboard
Generated by RelativeCI Documentation Report issue
821a19c to
36bc8e0
Compare
36bc8e0 to
537e52c
Compare
This PR contains the following updates:
1.25.2→1.26.0GitHub Vulnerability Alerts
CVE-2026-25536
Summary
Cross-client data leak via two distinct issues: (1) reusing a single
StreamableHTTPServerTransportacross multiple client requests, and (2) reusing a singleMcpServer/Serverinstance across multiple transports. Both are most common in stateless deployments.Impact
This advisory covers two related but distinct vulnerabilities. A deployment may be affected by one or both.
Issue 1: Transport re-use
What happens: When a single
StreamableHTTPServerTransportinstance handles multiple client requests, JSON-RPC message ID collisions cause responses to be routed to the wrong client's HTTP connection. The transport maintains an internalrequestId → streammapping, and since MCP client SDKs generate message IDs using an incrementing counter starting at 0, two clients produce identical IDs. The second client's request overwrites the first client's mapping entry, routing the response to the wrong HTTP stream.What is affected: All request types —
tools/call,resources/read,prompts/get, etc. No server-initiated features are required to trigger this.Conditions:
StreamableHTTPServerTransportinstance is reused across multiple client requests (most common in stateless mode withoutsessionIdGenerator)Issue 2: Server/Protocol re-use
What happens: When a single
McpServer(orServer) instance isconnect()ed to multiple transports (one per client), the Protocol's internalthis._transportreference is silently overwritten. The final response to a request is routed correctly (the Protocol captures the transport reference at request time), but any server-to-client messages sent during request handling use the sharedthis._transportreference, which may point to a different client's transport.What is affected: This depends on what features your server uses:
arrived before the transport was overwritten), the captured reference is correct and
the response routes properly.
this._transport, the captured reference points to the new transport, and the response
is mis-routed. The requesting client will time out.
sendNotification: Affected. These are dispatched throughthis._transport. When the transport has been overwritten and message IDs collide on the new transport, notifications are routed to the wrong client's HTTP stream.createMessage) and elicitation requests sent during tool execution viasendRequest: Affected. Same mechanism — the request is sent to the wrong client.Conditions:
McpServer/Serverinstance isconnect()ed to multiple transports across requests or sessionsHow to tell if you're affected
sessionIdGenerator(stateful mode) with a newMcpServerper session → not affected by either issue. Each session has its own transport and server instance.sessionIdGeneratorbut share a singleMcpServeracross sessions → not affected by Issue 1 (transport re-use), but affected by Issue 2 (server re-use) if your tools send progress notifications, sampling, or elicitation during execution.Patches
The fix (v1.26.0) adds runtime guards that turn silent data misrouting into immediate, actionable errors:
Protocol.connect()now throws if the protocol is already connected to a transport, preventing silent transport overwriting (addresses Issue 2)StreamableHTTPServerTransport.handleRequest()now throws if called more than once, enforcing one-request-per-transport in stateless mode (addresses Issue 1)close(), andsendNotification/sendRequestin handler extras check the abort signal before sending, preventing messages from leaking after a transport is replacedServers that were incorrectly reusing instances will now receive a clear error message directing them to create separate instances per connection.
Workarounds
If you cannot upgrade immediately, ensure your server creates fresh
McpServerand transport instances for each request (stateless) or session (stateful):Release Notes
modelcontextprotocol/typescript-sdk (@modelcontextprotocol/sdk)
v1.26.0Compare Source
Addresses "Sharing server/transport instances can leak cross-client response data" in this GHSA GHSA-345p-7cg4-v4c7
What's Changed
New Contributors
Full Changelog: modelcontextprotocol/typescript-sdk@v1.25.3...v1.26.0
v1.25.3Compare Source
What's Changed
Full Changelog: modelcontextprotocol/typescript-sdk@v1.25.2...v1.25.3
Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR was generated by Mend Renovate. View the repository job log.