Skip to content

chore(deps): update dependency mcp to v1.28.1 [security] - #170

Open
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-mcp-vulnerability
Open

chore(deps): update dependency mcp to v1.28.1 [security]#170
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-mcp-vulnerability

Conversation

@renovate

@renovate renovate Bot commented Jul 6, 2026

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
mcp ==1.19.0==1.28.1 age confidence

Model Context Protocol (MCP) Python SDK does not enable DNS rebinding protection by default

CVE-2025-66416 / GHSA-9h52-p55h-vw2f

More information

Details

Description

The Model Context Protocol (MCP) Python 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 using FastMCP with streamable HTTP or SSE transport, and has not configured TransportSecuritySettings, 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 FastMCP() now have DNS rebinding protection enabled by default when the host parameter is 127.0.0.1 or localhost. Users are advised to update to version 1.23.0 to receive this automatic protection. Users with custom low-level server configurations using StreamableHTTPSessionManager or SseServerTransport directly should explicitly configure TransportSecuritySettings when running an unauthenticated server on localhost.

Severity

  • CVSS Score: 7.6 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


MCP Python SDK: HTTP transports serve session requests without verifying the authenticated principal

CVE-2026-52869 / GHSA-jpw9-pfvf-9f58

More information

Details

Summary

In affected versions, the SSE and Streamable HTTP server transports routed incoming requests to an existing session based only on the session identifier, without verifying that the request was authenticated as the same principal that created the session. Anyone who learned or guessed a session ID could send JSON-RPC messages on that session, regardless of which bearer token the request carried.

Am I affected?

Only if a developer's application server uses an HTTP transport (SSE, or Streamable HTTP in stateful mode) and authenticates requests. Servers on stdio, stateless Streamable HTTP, or with no authentication configured are not affected.

Details

Both transports look up the target session by its identifier alone — the session_id query parameter for SSE (mcp.server.sse.SseServerTransport) and the Mcp-Session-Id header for Streamable HTTP (mcp.server.streamable_http_manager.StreamableHTTPSessionManager). Once the lookup succeeded, the request was handled on that session without comparing its authentication context to the credentials presented when the session was created, so a request authenticated as a different OAuth client could inject messages into the session. On the SSE transport the response is delivered to the original client's event stream; on the Streamable HTTP transport it is returned on the injecting request, so the injecting client can also read the result. The SSE transport has been affected since the first release; the Streamable HTTP transport since version 1.8.0.

Impact

Servers using either HTTP transport together with the SDK's built-in bearer-token authentication are affected: the per-client isolation that authentication provides can be bypassed for any session whose ID is known. Session IDs are randomly generated UUIDs, so exploitation requires obtaining one out of band (logs, network observation). Servers that do not enable bearer-token authentication have no per-client isolation to bypass and are not addressed by this advisory, and stateless Streamable HTTP deployments do not maintain sessions and are unaffected.

Mitigation

Upgrade to version 1.27.2 or later, which records the authenticated principal that created each session — the OAuth client ID together with the token's issuer and subject when the token verifier supplies them — and answers requests presenting a different principal with the same 404 response as for an unknown session.

Deployments where many end users share a single OAuth client (hosted MCP clients, gateways) should ensure their token verifier populates AccessToken.subject (e.g. from the token's sub claim) so sessions are isolated per user rather than per client. Deployments using a custom authentication backend other than the built-in BearerAuthBackend should enforce an equivalent check themselves.

Severity

  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


MCP Python SDK: WebSocket server transport does not support Host/Origin validation

CVE-2026-59950 / GHSA-vj7q-gjh5-988w

More information

Details

Summary

In affected versions, the deprecated WebSocket server transport (mcp.server.websocket.websocket_server) accepted the WebSocket handshake without applying any Host or Origin header validation. The TransportSecuritySettings mechanism that the SSE and Streamable HTTP transports use for this purpose was not wired into the WebSocket transport, so there was no SDK-level way to restrict which origins could connect.

Am I affected?

Only if a developer's application server exposes mcp.server.websocket.websocket_server. This transport has never been part of the MCP specification, is marked deprecated, and is not reachable through FastMCP — a developer must have wired it into an ASGI application themselves. Servers using stdio, SSE, or Streamable HTTP are not affected by this advisory.

Details

websocket_server() constructed a Starlette WebSocket and called accept(subprotocol="mcp") immediately, with no inspection of the connection's headers. By contrast, SseServerTransport and StreamableHTTPServerTransport accept an optional security_settings: TransportSecuritySettings and run TransportSecurityMiddleware.validate_request() against the incoming Host and Origin headers before establishing a session. Because browsers attach an Origin header to cross-origin WebSocket upgrade requests but do not enforce a same-origin policy on the response, a web page served from any origin could open a WebSocket to a reachable MCP server on this transport, complete the initialize handshake, and issue JSON-RPC requests on the resulting session.

Impact

A user who runs an MCP server on this transport bound to localhost or a LAN address, without a separate authentication or origin gate in front of it, and visits a malicious web page, can have that page enumerate and invoke the server's tools and read its resources. The consequences depend entirely on what the server exposes. The transport itself requires no token or prior session. Some browsers prompt before allowing a public page to open a connection to a local-network address, which adds a user-interaction step but is not a substitute for server-side validation.

Mitigation

Upgrade to version 1.28.1 or later, in which websocket_server() accepts the same optional security_settings: TransportSecuritySettings argument as the other HTTP-based transports and validates the Host and Origin headers before accepting the handshake; a request that fails validation is rejected with HTTP 403 and ValueError("Request validation failed") is raised to the caller. As with the other transports the parameter defaults to None, which leaves validation disabled, so upgrading alone does not change behaviour: pass a TransportSecuritySettings with enable_dns_rebinding_protection=True and appropriate allowed_hosts / allowed_origins to receive the protection. The recommended path remains to migrate off this deprecated transport to Streamable HTTP, where FastMCP enables this protection automatically for localhost binds. The WebSocket transport has been removed entirely in v2.

Severity

  • CVSS Score: 7.6 / 10 (High)
  • Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


Release Notes

modelcontextprotocol/python-sdk (mcp)

v1.28.1

Compare Source

What's Changed

  • [v1.x] Buffer per-request StreamableHTTP streams; store priming event before dispatch by @​maxisbey in #​2948
  • [v1.x] Set Development Status classifier to Production/Stable by @​maxisbey in #​2976
  • [v1.x] Support TransportSecuritySettings in the WebSocket server transport by @​maxisbey in #​2992

Full Changelog: modelcontextprotocol/python-sdk@v1.28.0...v1.28.1

v1.28.0

Compare Source

Deprecations

Two API surfaces now emit DeprecationWarning ahead of their removal in v2. Nothing is removed in 1.x, and the warnings fire only when the deprecated API is called - importing the modules stays silent.

  • WebSocket transport - mcp.client.websocket.websocket_client and mcp.server.websocket.websocket_server. WebSocket was never part of the MCP specification; use the streamable HTTP transport instead. The TypeScript SDK has likewise removed its WebSocket client for v2 (modelcontextprotocol/typescript-sdk#1783).
  • Experimental tasks API - ClientSession.experimental, Server.experimental, ServerSession.experimental, and the experimental_task_handlers= kwarg on ClientSession. Tasks (SEP-1686) were removed from the MCP specification and are expected to return as a separate MCP extension.

If your test suite runs with filterwarnings = ["error"] and exercises these paths, add a scoped ignore such as ignore:The experimental tasks API is deprecated:DeprecationWarning or ignore:The WebSocket .* transport is deprecated:DeprecationWarning.

See #​2828 for full details.

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/python-sdk@v1.27.2...v1.28.0

v1.27.2

Compare Source

What's Changed

Full Changelog: modelcontextprotocol/python-sdk@v1.27.1...v1.27.2

v1.27.1

Compare Source

What's Changed

Full Changelog: modelcontextprotocol/python-sdk@v1.27.0...v1.27.1

v1.27.0

Compare Source

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/python-sdk@v1.26.0...v1.27.0

v1.26.0

Compare Source

What's Changed

Full Changelog: modelcontextprotocol/python-sdk@v1.25.0...v1.26.0

v1.25.0

Compare Source

Branching Update

Starting with this release, the repository has adopted a new branching strategy for v2 development:

  • main — v2 development (breaking changes)
  • v1.x — v1 maintenance (security and critical bug fixes only, with very rare feature additions ported from main)

Users who need to stay on v1.x should pin to mcp>=1.25,<2.

The current plan is to work through v2 and have it released some time in Q1. This also relies on the next upcoming spec release which will heavily change how the transport layer works, which in turn will guide a lot of how we architect v2.


What's Changed

New Contributors

Full Changelog: modelcontextprotocol/python-sdk@v1.24.0...v1.25.0

v1.24.0

Compare Source

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/python-sdk@v1.23.3...v1.24.0

v1.23.3

Compare Source

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/python-sdk@v1.23.2...v1.23.3

v1.23.2

Compare Source

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/python-sdk@v1.23.1...v1.23.2

v1.23.1

Compare Source

What's Changed

Full Changelog: modelcontextprotocol/python-sdk@v1.23.0...v1.23.1

v1.23.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/python-sdk@v1.22.0...v1.23.0

v1.22.0

Compare Source

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/python-sdk@v1.21.1...v1.22.0

v1.21.2

Compare Source

Hotfix Release

This is a hotfix release to address a critical bug in OAuth scope handling that caused failures on 401 responses.

Related:

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/python-sdk@v1.21.1...v1.21.2

v1.21.1

Compare Source

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/python-sdk@v1.21.0...v1.21.1

v1.21.0

Compare Source

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/python-sdk@v1.20.0...v1.21.0

v1.20.0

Compare Source

What's Changed

New Contributors

Full Changelog: modelcontextprotocol/python-sdk@v1.19.0...v1.20.0


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • 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.

@renovate
renovate Bot force-pushed the renovate/pypi-mcp-vulnerability branch 7 times, most recently from 7e19f10 to 7ddcc61 Compare July 13, 2026 08:59
@renovate
renovate Bot force-pushed the renovate/pypi-mcp-vulnerability branch 8 times, most recently from 9afeaf3 to 150395d Compare July 17, 2026 08:50
@renovate renovate Bot changed the title chore(deps): update dependency mcp to v1.23.0 [security] chore(deps): update dependency mcp to v1.28.1 [security] Jul 17, 2026
@renovate
renovate Bot force-pushed the renovate/pypi-mcp-vulnerability branch 2 times, most recently from 8e22876 to 3bb2f4f Compare July 27, 2026 09:02
@renovate
renovate Bot force-pushed the renovate/pypi-mcp-vulnerability branch from 3bb2f4f to 2e5921e Compare August 5, 2026 13:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants