Skip to content

chore(deps): update dependency @modelcontextprotocol/sdk to v1.26.0 [security]#2196

Open
renovate[bot] wants to merge 1 commit intomainfrom
renovate/npm-modelcontextprotocol-sdk-vulnerability
Open

chore(deps): update dependency @modelcontextprotocol/sdk to v1.26.0 [security]#2196
renovate[bot] wants to merge 1 commit intomainfrom
renovate/npm-modelcontextprotocol-sdk-vulnerability

Conversation

@renovate
Copy link
Contributor

@renovate renovate bot commented Feb 4, 2026

This PR contains the following updates:

Package Change Age Confidence
@modelcontextprotocol/sdk (source) 1.25.21.26.0 age confidence

GitHub Vulnerability Alerts

CVE-2026-25536

Summary

Cross-client data leak via two distinct issues: (1) reusing a single StreamableHTTPServerTransport across multiple client requests, and (2) reusing a single McpServer/Server instance 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 StreamableHTTPServerTransport instance 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 internal requestId → stream mapping, 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:

  • A single StreamableHTTPServerTransport instance is reused across multiple client requests (most common in stateless mode without sessionIdGenerator)
  • Two or more clients send requests concurrently
  • Clients generate overlapping JSON-RPC message IDs (the SDK's default client uses an incrementing counter starting at 0)

Issue 2: Server/Protocol re-use

What happens: When a single McpServer (or Server) instance is connect()ed to multiple transports (one per client), the Protocol's internal this._transport reference 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 shared this._transport reference, which may point to a different client's transport.

What is affected: This depends on what features your server uses:

  • Final responses (the return value from a tool/resource/prompt handler): Affected in most cases. The Protocol captures this._transport at request-handling time, not the transport that delivered the request. This means:
    • If a request is already in-flight when a second connect() occurs (i.e., the request
      arrived before the transport was overwritten), the captured reference is correct and
      the response routes properly.
    • If a request arrives on the old transport after a second connect() has overwritten
      this._transport, the captured reference points to the new transport, and the response
      is mis-routed. The requesting client will time out.
  • Progress notifications sent during tool execution via sendNotification: Affected. These are dispatched through this._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.
  • Sampling (createMessage) and elicitation requests sent during tool execution via sendRequest: Affected. Same mechanism — the request is sent to the wrong client.
  • Spontaneous server-initiated notifications (outside any request handler): Affected. These are sent to whichever client's transport was most recently connected.

Conditions:

  • A single McpServer/Server instance is connect()ed to multiple transports across requests or sessions
  • Two or more clients connect concurrently
  • For in-request notifications/requests: message ID collision on the other transport is required for silent data leaking (the SDK's default client uses an incrementing counter starting at 0). Without collision, the transport will throw an error rather than misroute.
  • For spontaneous notifications: no collision needed, messages are always sent to the last-connected client's transport

How to tell if you're affected

  • You use sessionIdGenerator (stateful mode) with a new McpServer per session → not affected by either issue. Each session has its own transport and server instance.
  • You use sessionIdGenerator but share a single McpServer across 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.
  • You are in stateless mode and reuse both a transport and a server across requests → affected by both issues; all request types can leak.
  • You are in stateless mode and create a new transport per request, but reuse the server → affected by Issue 2 only; safe if your tools only return results without sending progress notifications, sampling, or elicitation during execution.
  • You create a new server + transport per request → not affected.
  • Single-client environments (e.g., local development with one IDE) → not affected.

Patches

The fix (v1.26.0) adds runtime guards that turn silent data misrouting into immediate, actionable errors:

  1. Protocol.connect() now throws if the protocol is already connected to a transport, preventing silent transport overwriting (addresses Issue 2)
  2. Stateless StreamableHTTPServerTransport.handleRequest() now throws if called more than once, enforcing one-request-per-transport in stateless mode (addresses Issue 1)
  3. In-flight request handler abort controllers are cleaned up on close(), and sendNotification/sendRequest in handler extras check the abort signal before sending, preventing messages from leaking after a transport is replaced

Servers 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 McpServer and transport instances for each request (stateless) or session (stateful):

// Stateless mode: create new server + transport per request
app.post('/mcp', async (req, res) => {
  const server = new McpServer({ name: 'my-server', version: '1.0.0' });
  // ... register tools, resources, etc.
  const transport = new StreamableHTTPServerTransport({ sessionIdGenerator: undefined });
  await server.connect(transport);
  await transport.handleRequest(req, res);
});

// Stateful mode: create new server + transport per session
const sessions = new Map();
app.post('/mcp', async (req, res) => {
  const sessionId = req.headers['mcp-session-id'];
  if (sessions.has(sessionId)) {
    await sessions.get(sessionId).transport.handleRequest(req, res);
  } else {
    const server = new McpServer({ name: 'my-server', version: '1.0.0' });
    // ... register tools, resources, etc.
    const transport = new StreamableHTTPServerTransport({
      sessionIdGenerator: () => randomUUID()
    });
    await server.connect(transport);
    sessions.set(transport.sessionId, { server, transport });
    await transport.handleRequest(req, res);
  }
});

Release Notes

modelcontextprotocol/typescript-sdk (@​modelcontextprotocol/sdk)

v1.26.0

Compare 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.3

Compare Source

What's Changed

  • [v1.x backport] Use correct schema for client sampling validation when tools are present by @​olaservo in #​1407
  • fix: prevent Hono from overriding global Response object (v1.x) by @​mattzcarey in #​1411

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.


  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate bot added the bot:renovate This is from bot 'renovate' label Feb 4, 2026
@changeset-bot
Copy link

changeset-bot bot commented Feb 4, 2026

⚠️ No Changeset found

Latest commit: 537e52c

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

@codecov
Copy link

codecov bot commented Feb 4, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

@codspeed-hq
Copy link

codspeed-hq bot commented Feb 4, 2026

Merging this PR will improve performance by 5.25%

⚡ 1 improved benchmark
✅ 62 untouched benchmarks
⏩ 3 skipped benchmarks1

Performance Changes

Benchmark BASE HEAD Efficiency
transform 1000 view elements 45.6 ms 43.3 ms +5.25%

Comparing renovate/npm-modelcontextprotocol-sdk-vulnerability (537e52c) with main (7e27895)

Open in CodSpeed

Footnotes

  1. 3 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports.

@relativeci
Copy link

relativeci bot commented Feb 4, 2026

Web Explorer

#7715 Bundle Size — 383.74KiB (0%).

537e52c(current) vs 7e27895 main#7709(baseline)

Bundle metrics  Change 1 change
                 Current
#7715
     Baseline
#7709
No change  Initial JS 154.88KiB 154.88KiB
No change  Initial CSS 35.06KiB 35.06KiB
No change  Cache Invalidation 0% 0%
No change  Chunks 8 8
No change  Assets 8 8
Change  Modules 237(-0.42%) 238
No change  Duplicate Modules 16 16
No change  Duplicate Code 2.99% 2.99%
No change  Packages 4 4
No change  Duplicate Packages 0 0
Bundle size by type  no changes
                 Current
#7715
     Baseline
#7709
No change  JS 252.83KiB 252.83KiB
No change  Other 95.85KiB 95.85KiB
No change  CSS 35.06KiB 35.06KiB

Bundle analysis reportBranch renovate/npm-modelcontextprotoco...Project dashboard


Generated by RelativeCIDocumentationReport issue

@renovate renovate bot force-pushed the renovate/npm-modelcontextprotocol-sdk-vulnerability branch from 821a19c to 36bc8e0 Compare February 12, 2026 11:39
@renovate renovate bot force-pushed the renovate/npm-modelcontextprotocol-sdk-vulnerability branch from 36bc8e0 to 537e52c Compare February 17, 2026 18:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bot:renovate This is from bot 'renovate'

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants