Update dependency @modelcontextprotocol/sdk to v1.26.0 [SECURITY] by renovate[bot] · Pull Request #23 · zerocracy/zerocracy-mcp-server

renovate · 2025-12-02T18:34:42Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
@modelcontextprotocol/sdk (source)	`1.11.0` → `1.26.0`

GitHub Vulnerability Alerts

CVE-2025-66414

The Model Context Protocol (MCP) TypeScript SDK does not enable DNS rebinding protection by default for HTTP-based servers. When an HTTP-based MCP server is run on localhost without authentication with StreamableHTTPServerTransport or SSEServerTransport and has not enabled enableDnsRebindingProtection, a malicious website could exploit DNS rebinding to bypass same-origin policy restrictions and send requests to the local MCP server. This could allow an attacker to invoke tools or access resources exposed by the MCP server on behalf of the user in those limited circumstances.

Note that running HTTP-based MCP servers locally without authentication is not recommended per MCP security best practices. This issue does not affect servers using stdio transport.

Servers created via createMcpExpressApp() now have this protection enabled by default when binding to localhost. Users with custom Express configurations are advised to update to version 1.24.0 and apply the exported hostHeaderValidation() middleware when running an unauthenticated server on localhost.

CVE-2026-0621

Impact

A ReDoS vulnerability in the UriTemplate class allows attackers to cause denial of service. The partToRegExp() function generates a regex pattern with nested quantifiers (([^/]+(?:,[^/]+)*)) for exploded template variables (e.g., {/id*}, {?tags*}), causing catastrophic backtracking on malicious input.

Who is affected: MCP servers that register resource templates with exploded array patterns and accept requests from untrusted clients.

Attack result: An attacker sends a crafted URI via resources/read request, causing 100% CPU utilization, server hang/crash, and denial of service for all clients.

Affected Versions

All versions of @modelcontextprotocol/sdk prior to the patched release.

Patches

v1.25.2 contains b392f02ffcf37c088dbd114fedf25026ec3913d3 the fix modifies the regex pattern to prevent backtracking.

Workarounds

Avoid using exploded patterns ({/id*}, {?tags*}) in resource templates
Implement request timeouts and rate limiting
Validate URIs before processing to reject suspicious patterns

CVE-2026-25536

Summary

Cross-client response data leak when a single McpServer/Server and transport instance is reused across multiple client connections, most commonly in stateless StreamableHTTPServerTransport deployments.

Impact

Who is affected: Any MCP server deployment using the TypeScript SDK where a single McpServer (or Server) instance is shared across multiple concurrent client connections. This is most likely in stateless mode (no sessionIdGenerator), where the natural but incorrect pattern is to create one server and transport and handle all requests through it. Stateful mode is also affected if the server instance is improperly shared across sessions, though this misconfiguration is less common since the stateful pattern naturally encourages per-session instances.

What happens: When two or more MCP clients send requests concurrently through a shared server instance, JSON-RPC message ID collisions cause responses to be routed to the wrong client's HTTP connection. Client A can receive response data intended for Client B, and vice versa, even when authorization was correctly enforced on each individual request.

The MCP SDK's client generates message IDs using a simple incrementing counter starting at 0. When two clients connect to the same server instance, they produce identical message IDs, causing the transport's internal request-to-stream mapping to overwrite one client's entry with another's — routing responses to the wrong HTTP connection.

Conditions for exploitation:

The server reuses a single McpServer/Server instance across requests or sessions (rather than creating fresh instances per request/session)
Two or more clients connect concurrently
Clients generate overlapping JSON-RPC message IDs (virtually guaranteed since the SDK's client uses an incrementing counter starting at 0)

Not affected:

Stateful servers that create a new McpServer + transport per session (the typical and recommended stateful pattern)
Stateless servers that create a new McpServer + transport per request
Single-client environments (e.g., local development with one IDE)

Patches

The fix 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 across both stateful and stateless modes
Stateless StreamableHTTPServerTransport.handleRequest() now throws if called more than once, enforcing one-request-per-transport in stateless mode

Servers that were incorrectly reusing instances will now receive a clear error message directing them to create separate instances per connection.

Workarounds

If projects cannot upgrade immediately, ensure the 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);
  }
});

Resources

Release Notes

modelcontextprotocol/typescript-sdk (@modelcontextprotocol/sdk)

Conversation

renovate bot commented Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

GitHub Vulnerability Alerts

Impact

Affected Versions

Patches

Workarounds

Summary

Impact

Patches

Workarounds

Resources

Release Notes

What's Changed

New Contributors

What's Changed

What's Changed

New Contributors

What's Changed

What's Changed

New Contributors

What's Changed

What's Changed

New Contributors

What's Changed

New Contributors

Summary

What's Changed

New Contributors

Fixed:

What's Changed

New Contributors

What's Changed

New Contributors

What's changed

What's Changed

New Contributors

What's Changed

New Contributors

What's Changed

New Contributors

What's Changed

New Contributors

What's Changed

New Contributors 🙏

What's Changed

New Contributors

What's Changed

New Contributors

What's Changed

New Contributors

What's Changed

What's Changed

What's Changed

New Contributors

Configuration

Uh oh!

coderabbitai bot commented Dec 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Review skipped

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

renovate bot commented Dec 2, 2025 •

edited

Loading

coderabbitai bot commented Dec 2, 2025 •

edited

Loading