Skip to content

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

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]#287
renovate[bot] wants to merge 1 commit intomainfrom
renovate/npm-modelcontextprotocol-sdk-vulnerability

Conversation

@renovate
Copy link
Contributor

@renovate renovate bot commented Dec 2, 2025 •
edited
Loading

This PR contains the following updates:

Package Change Age Confidence
@modelcontextprotocol/sdk (source) 1.22.0 → 1.26.0 age confidence

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 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

v1.25.2

Compare Source

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/typescript-sdk@1.25.1...v1.25.2

v1.25.1

Compare Source

What's Changed

Full Changelog: modelcontextprotocol/typescript-sdk@1.25.0...1.25.1

v1.25.0

Compare Source

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/typescript-sdk@1.24.3...1.25.0

v1.24.3

Compare Source

What's Changed

Full Changelog: modelcontextprotocol/typescript-sdk@1.24.2...1.24.3

v1.24.2

Compare Source

What's Changed
New Contributors

Full Changelog: modelcontextprotocol/typescript-sdk@1.24.1...1.24.2

v1.24.1

Compare Source

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/typescript-sdk@1.24.0...1.24.1

v1.24.0

Compare Source

Summary

This release brings us up to speed with the latest MCP spec 2025-11-25. Take a look at the latest spec as well as the release blog post.

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/typescript-sdk@1.23.0...1.24.0

v1.23.1

Compare Source

Fixed:

  • Disabled SSE priming events to fix backwards compatibility - 1.23.x clients crash on empty SSE data (JSON.parse(""))

This is a patch for servers still on 1.23.x that were breaking clients not handling the the 2025-11-25 priming event behavior with empty SSE data fields. See #​1233 for more details.

Full Changelog: modelcontextprotocol/typescript-sdk@1.23.0...1.23.1

v1.23.0

Compare Source

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/typescript-sdk@1.22.0...1.23.0

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 this update again.

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

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

@claude
Copy link
Contributor

claude bot commented Dec 2, 2025

Code Review: Security Update - @modelcontextprotocol/sdk v1.24.0

Overview

This is a critical security update from Renovate that addresses CVE-2025-66414 (DNS rebinding vulnerability) and includes several important improvements to the MCP TypeScript SDK.

✅ Security Analysis

CVE-2025-66414: DNS Rebinding Protection

Severity: Medium-High (for affected configurations)
Impact: This project uses stdio transport (StdioServerTransport), which is NOT affected by this vulnerability.

Verification:

  • ✅ Reviewed src/index.ts:6 - Uses StdioServerTransport exclusively
  • ✅ No HTTP-based transports (StreamableHTTPServerTransport, SSEServerTransport) found in codebase
  • ✅ No Express-based MCP server configurations present

Conclusion: While this is a security advisory, this project is not vulnerable due to transport choice. However, upgrading is still recommended for staying current and future-proofing.

📊 Change Analysis

What Changed

Package Updates:

  • @modelcontextprotocol/sdk: 1.22.0 → 1.24.0 (2 minor versions)
  • New dependency: jose v6.1.3 (JWT/JOSE implementation)
  • Updated peer dependency: zod now supports both ^3.25 and ^4.0

Key Changes from Release Notes:

Version 1.23.0

  • ✅ Migrated from Jest to Vitest (internal SDK change)
  • ✅ Zod v4 support with backwards compatibility
  • ✅ URL-based client metadata registration (SEP-991)
  • ✅ Sampling with tools implementation (SEP-1577)
  • ✅ Authentication scope management improvements (SEP-835, SEP-1613)
  • ✅ Form mode elicitation request schema updates

Version 1.24.0

  • 🔒 DNS rebinding protection enabled by default (CVE-2025-66414)
  • ✅ SSE polling via server-side disconnect (SEP-1699)
  • ✅ Enhanced auth request handling

🔍 Compatibility Assessment

✅ COMPATIBLE - No Breaking Changes Detected

Zod Compatibility:

  • This project uses: zod@^4.1.13 (package.json:62)
  • SDK now supports: zod@^3.25 || ^4.0
  • ✅ Fully compatible - Zod v4 is explicitly supported

API Usage:

  • ✅ Server class - No breaking changes
  • ✅ StdioServerTransport - No breaking changes
  • ✅ CallToolRequest type - No breaking changes
  • ✅ Schema types (CallToolRequestSchema, ListToolsRequestSchema) - No breaking changes

New Optional Features:

  • Auth enhancements - Not currently used by this project
  • URL elicitation - Not currently used
  • SSE transport improvements - Not currently used

🧪 Testing Recommendations

Pre-Merge Testing

# 1. Install dependencies
npm install

# 2. Run full quality gates (per CLAUDE.md)
make lint          # TypeScript/JavaScript linting
make test          # Full test suite (85-90%+ coverage target)
make build         # Verify TypeScript compilation

# 3. Integration testing
npm run dev        # Test server startup
# Test actual MCP tool invocations with Claude Desktop

Expected Results

  • ✅ All linting passes (zero errors)
  • ✅ 100% test pass rate
  • ✅ Clean TypeScript build
  • ✅ Server starts without errors
  • ✅ MCP tools respond correctly

📋 Quality Gate Checklist

Based on project's CLAUDE.md requirements:

  • Security Review: CVE addressed, no vulnerabilities introduced
  • Dependency Analysis: Only SDK and transitive deps updated
  • Breaking Changes: None detected
  • API Compatibility: All imports/types remain valid
  • Linting: Run make lint before merge
  • Testing: Run make test before merge (90%+ coverage)
  • Build: Run make build before merge
  • Integration: Test with Claude Desktop

🎯 Recommendation

APPROVE with CI Verification

Rationale:

  1. ✅ Critical security fix (even if not directly affected)
  2. ✅ No breaking changes for this codebase
  3. ✅ Zod v4 compatibility explicitly supported
  4. ✅ Minimal scope (package-lock.json only)
  5. ✅ Follows semantic versioning (1.22.0 → 1.24.0)

Action Items:

  1. ✅ Wait for CI checks to complete (GitHub Actions must pass)
  2. ✅ Verify all quality gates pass (lint, test, build)
  3. ✅ Test locally if CI is green
  4. ✅ Merge when all checks pass

📝 Notes

Why merge even if not vulnerable?

  • Staying current reduces future security debt
  • Includes important auth and schema improvements
  • Future features may use HTTP transports
  • Renovate tracks this as a security update

Rollback Plan (if issues arise):

git revert HEAD
npm install
make check

References

@claude claude bot mentioned this pull request Dec 3, 2025
Open
1 task
@claude
Copy link
Contributor

claude bot commented Dec 3, 2025

Code Review: Security Update for @modelcontextprotocol/sdk

Summary

This PR updates the MCP SDK from v1.22.0 to v1.24.0 to address CVE-2025-66414, a DNS rebinding vulnerability affecting HTTP-based MCP servers running on localhost without authentication.

Security Analysis

✅ Critical Security Fix

  • CVE-2025-66414: DNS rebinding protection now enabled by default for HTTP-based servers
  • Impact: Prevents malicious websites from exploiting DNS rebinding to bypass same-origin policy
  • Severity: Important to merge, especially if using StreamableHTTPServerTransport or SSEServerTransport

Note: This project appears to use stdio transport (based on codebase architecture), so the direct impact is lower, but updating is still recommended for security best practices.

Dependency Changes

✅ Proper Dependency Management

  1. New dependency: jose@^6.1.1 (JWT/JWE/JWS library)

    • Legitimate addition for authentication features
    • Well-maintained, trusted library from panva
    • No known vulnerabilities

  2. Zod version handling:

    • SDK now supports both Zod v3.25+ and v4.0+: "zod": "^3.25 || ^4.0"
    • Project uses Zod v4.1.13 (package.json:62) ✅ Compatible
    • Zod moved from bundled dependency to peer dependency (better for version conflicts)
    • zod-to-json-schema updated to v3.25.0

  3. Removed bundled Zod:

    • SDK previously bundled its own Zod v3.25.76
    • Now relies on peer dependency - reduces duplication and potential conflicts

Code Quality Observations

✅ All CI Checks Passing

  • Lint: SUCCESS
  • Tests: SUCCESS
  • Build: SUCCESS
  • Security Audit: SUCCESS
  • Integration Tests (Ubuntu/Windows/macOS): SUCCESS
  • Docker Build: SUCCESS
  • Claude Review: SUCCESS

✅ Minimal Surface Area

  • Only changes package-lock.json
  • No code changes required
  • Low risk of breaking changes

Potential Concerns

⚠️ Breaking Changes to Consider

  1. Zod Peer Dependency:

    • SDK now requires Zod as a peer dependency (not optional)
    • Project already has Zod v4.1.13 installed ✅
    • But ensure all SDK features work with Zod v4 (SDK advertises v3.25+ OR v4.0+ support)

  2. Authentication Changes:

    • New jose dependency suggests authentication features added
    • Review v1.23.0 release notes for API changes:
      • URL-based client metadata registration (SEP 991)
      • OAuth scope management changes (SEP-835)
      • Upscoping on insufficient_scope 403
    • If project uses MCP SDK authentication features, test thoroughly

  3. Schema Changes:

    • SDK now uses .catchall() on input/output schemas (JSON Schema 2020-12 support)
    • May affect tools with strict schema validation

Recommendations

✅ APPROVE with monitoring

  1. Immediate Actions:

    • Merge this PR (security fix is important)
    • Monitor for runtime issues after deployment

  2. Post-Merge Validation:

    • Run integration tests in development environment
    • Verify all MCP tools still function correctly
    • Check for any Zod v4 compatibility issues with SDK schemas

  3. Future Consideration:

    • Review SDK v1.23.0 and v1.24.0 release notes for new features
    • Consider adopting new authentication patterns if applicable
    • Update codebase to use latest MCP SDK patterns (SEP-1577: Sampling With Tools, SEP-1699: SSE polling)

Additional Notes

  • Renovate Configuration: Consider enabling auto-merge for security patches with passing CI
  • Dependency Monitoring: Subscribe to MCP SDK security advisories
  • Testing: All automated checks passed, indicating good compatibility

Verdict: ✅ Safe to merge. Security fix is critical, changes are minimal, and all CI checks pass. Monitor for any Zod v4 compatibility issues post-merge.

@renovate renovate bot changed the title chore(deps): update dependency @modelcontextprotocol/sdk to v1.24.0 [security] chore(deps): update dependency @modelcontextprotocol/sdk to v1.25.2 [security] Jan 7, 2026
@renovate renovate bot force-pushed the renovate/npm-modelcontextprotocol-sdk-vulnerability branch from e2cbd6d to 4e326c5 Compare January 7, 2026 20:42
@renovate renovate bot force-pushed the renovate/npm-modelcontextprotocol-sdk-vulnerability branch 2 times, most recently from 71ee189 to b6869a0 Compare January 23, 2026 18:08
@renovate renovate bot force-pushed the renovate/npm-modelcontextprotocol-sdk-vulnerability branch from b6869a0 to 8903ffc Compare February 2, 2026 19:37
@renovate renovate bot changed the title chore(deps): update dependency @modelcontextprotocol/sdk to v1.25.2 [security] chore(deps): update dependency @modelcontextprotocol/sdk to v1.26.0 [security] Feb 4, 2026
@renovate renovate bot force-pushed the renovate/npm-modelcontextprotocol-sdk-vulnerability branch from 8903ffc to e89edbd Compare February 4, 2026 21:48
@renovate renovate bot force-pushed the renovate/npm-modelcontextprotocol-sdk-vulnerability branch from e89edbd to d774e83 Compare February 12, 2026 18:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants