You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In affected versions, the default request handlers installed by the experimental tasks feature (server.experimental.enable_tasks()) did not check which session created a task before acting on it. On a server with more than one connected client, any client could observe, read results from, and cancel tasks belonging to other clients.
Am I affected?
Only if the developer's application server calls server.experimental.enable_tasks(). If grep -r enable_tasks over their codebase finds nothing, the application is not affected.
Details
When tasks support is enabled on the low-level server, default handlers are registered for tasks/list, tasks/get, tasks/result, and tasks/cancel. These handlers operated on the task identifier alone and kept no record of the session that created each task. Because tasks/list returned every task in the store, a connected client did not need to know any identifiers in advance: it could enumerate all tasks, read any task's status and result via tasks/get and tasks/result, retrieve queued task messages — such as elicitation requests intended for the task's creator, which are removed from the queue on delivery, so the intended recipient never receives them — and cancel any task via tasks/cancel.
Impact
Servers that call server.experimental.enable_tasks() and serve multiple clients are affected: one client can read other clients' task results and elicitation payloads, consume messages meant for them, and cancel their tasks. The feature is experimental and opt-in, so servers that never enable it are unaffected. Servers that registered their own task handlers instead of the defaults are affected only if those handlers have the same omission.
Mitigation
Upgrade to version 1.27.2 or later, in which task IDs generated by run_task() embed an opaque per-session marker and the default handlers restrict each session to its own tasks: requests for another session's task receive "task not found", and tasks/list returns only the requesting session's tasks. Tasks created with explicitly chosen IDs or written directly through a TaskStore remain reachable by ID but are not listed. Alternatively, leave the experimental tasks feature disabled, or register task handlers that validate session ownership.
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.
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.
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.
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer TIP This summary will be updated as you push new changes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
area:ci-cdContinuous integration and deployment pipelinesarea:docsKnowledge management and documentationarea:pythonPython development and toolingarea:securitySecurity and policy workarea:webAPIs, web services, or UI workbot:renovateAutomated dependency updates by RenovatedependenciesDependency updates or dependency issuestype:choreMaintenance, refactor, or tooling
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
type:chore
This PR contains the following updates:
1.27.0→1.28.1MCP Python SDK: Experimental task handlers allow any client to access and cancel other clients' tasks
CVE-2026-52870 / GHSA-hvrp-rf83-w775
More information
Details
Summary
In affected versions, the default request handlers installed by the experimental tasks feature (
server.experimental.enable_tasks()) did not check which session created a task before acting on it. On a server with more than one connected client, any client could observe, read results from, and cancel tasks belonging to other clients.Am I affected?
Only if the developer's application server calls
server.experimental.enable_tasks(). Ifgrep -r enable_tasksover their codebase finds nothing, the application is not affected.Details
When tasks support is enabled on the low-level server, default handlers are registered for
tasks/list,tasks/get,tasks/result, andtasks/cancel. These handlers operated on the task identifier alone and kept no record of the session that created each task. Becausetasks/listreturned every task in the store, a connected client did not need to know any identifiers in advance: it could enumerate all tasks, read any task's status and result viatasks/getandtasks/result, retrieve queued task messages — such as elicitation requests intended for the task's creator, which are removed from the queue on delivery, so the intended recipient never receives them — and cancel any task viatasks/cancel.Impact
Servers that call
server.experimental.enable_tasks()and serve multiple clients are affected: one client can read other clients' task results and elicitation payloads, consume messages meant for them, and cancel their tasks. The feature is experimental and opt-in, so servers that never enable it are unaffected. Servers that registered their own task handlers instead of the defaults are affected only if those handlers have the same omission.Mitigation
Upgrade to version 1.27.2 or later, in which task IDs generated by
run_task()embed an opaque per-session marker and the default handlers restrict each session to its own tasks: requests for another session's task receive "task not found", andtasks/listreturns only the requesting session's tasks. Tasks created with explicitly chosen IDs or written directly through aTaskStoreremain reachable by ID but are not listed. Alternatively, leave the experimental tasks feature disabled, or register task handlers that validate session ownership.Severity
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:LReferences
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_idquery parameter for SSE (mcp.server.sse.SseServerTransport) and theMcp-Session-Idheader 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'ssubclaim) so sessions are isolated per user rather than per client. Deployments using a custom authentication backend other than the built-inBearerAuthBackendshould enforce an equivalent check themselves.Severity
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:LReferences
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 anyHostorOriginheader validation. TheTransportSecuritySettingsmechanism 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 throughFastMCP— 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 StarletteWebSocketand calledaccept(subprotocol="mcp")immediately, with no inspection of the connection's headers. By contrast,SseServerTransportandStreamableHTTPServerTransportaccept an optionalsecurity_settings: TransportSecuritySettingsand runTransportSecurityMiddleware.validate_request()against the incomingHostandOriginheaders before establishing a session. Because browsers attach anOriginheader 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 theinitializehandshake, 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 optionalsecurity_settings: TransportSecuritySettingsargument as the other HTTP-based transports and validates theHostandOriginheaders before accepting the handshake; a request that fails validation is rejected with HTTP 403 andValueError("Request validation failed")is raised to the caller. As with the other transports the parameter defaults toNone, which leaves validation disabled, so upgrading alone does not change behaviour: pass aTransportSecuritySettingswithenable_dns_rebinding_protection=Trueand appropriateallowed_hosts/allowed_originsto receive the protection. The recommended path remains to migrate off this deprecated transport to Streamable HTTP, whereFastMCPenables this protection automatically for localhost binds. The WebSocket transport has been removed entirely in v2.Severity
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
modelcontextprotocol/python-sdk (mcp)
v1.28.1Compare Source
What's Changed
Full Changelog: modelcontextprotocol/python-sdk@v1.28.0...v1.28.1
v1.28.0Compare Source
Deprecations
Two API surfaces now emit
DeprecationWarningahead 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.mcp.client.websocket.websocket_clientandmcp.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).ClientSession.experimental,Server.experimental,ServerSession.experimental, and theexperimental_task_handlers=kwarg onClientSession. 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 asignore:The experimental tasks API is deprecated:DeprecationWarningorignore: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.2Compare Source
What's Changed
Full Changelog: modelcontextprotocol/python-sdk@v1.27.1...v1.27.2
v1.27.1Compare Source
What's Changed
Full Changelog: modelcontextprotocol/python-sdk@v1.27.0...v1.27.1
Configuration
📅 Schedule: (in timezone America/New_York)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.