Skip to content

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

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

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

Conversation

@renovate

@renovate renovate Bot commented Jul 19, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
mcp 1.26.0 → 1.30.0 age adoption passing confidence

MCP Python SDK: Experimental task handlers allow any client to access and cancel other clients' tasks

CVE-2026-52870 / GHSA-hvrp-rf83-w775 / PYSEC-2026-3481

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(). 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.

Severity

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

References

This data is provided by OSV and 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 / PYSEC-2026-3482

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 OSV and the GitHub Advisory Database (CC-BY 4.0).

MCP Python SDK: Experimental task handlers allow any client to access and cancel other clients' tasks

CVE-2026-52870 / GHSA-hvrp-rf83-w775 / PYSEC-2026-3481

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(). 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.

Severity

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

References

This data is provided by OSV and the PyPI 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 / PYSEC-2026-3482

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 OSV and the PyPI 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 / PYSEC-2026-3483

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 OSV and 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 / PYSEC-2026-3483

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 OSV and the PyPI Advisory Database (CC-BY 4.0).

Model Context Protocol Python SDK: HTTP client transports followed cross-origin redirects carrying custom headers and bodies

CVE-2026-116685 / GHSA-5h93-6whr-6q8j

More information

Details

Summary

In affected versions, the SDK's Streamable HTTP and SSE client transports followed HTTP redirects to any host. If the configured MCP endpoint answered with a redirect to a different origin:

  • custom headers set on the client (for example an X-API-Key credential) were sent to that origin, and
  • on a 307 or 308 redirect the request body was re-sent there too.

The SDK's OAuth client providers followed redirects on their own discovery, registration and token requests in the same way.

A lone Authorization bearer header was not exposed; the HTTP library already drops it on cross-origin redirects.

Anyone able to make an endpoint you trust redirect elsewhere (a stale redirect to a lapsed domain, a misrouted proxy rule, redirect logic an attacker can influence) could capture that material. A server that is itself malicious gains nothing this way; it already receives your requests directly.

Am I affected?

Yes, if your code uses the SDK as an MCP client over HTTP through any of:

  • streamable_http_client (on 2.x also Client given an http:// or https:// URL)
  • streamablehttp_client or sse_client
  • ClientSessionGroup with HTTP server parameters
  • the internal create_mcp_http_client helper

This includes an HTTP client you passed in yourself with follow_redirects=True.

Affected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.

Not affected:

  • MCP servers
  • stdio clients
  • a client you supplied with follow_redirects left at its default of False
Fix

Upgrade to mcp 1.30.0 (1.x) or 2.2.0 (2.x) or later; no code changes are needed.

The transports, and the OAuth providers' own requests, now follow a redirect only when it stays on the endpoint's origin (same scheme, host and port, or an http to https upgrade on the same host) and keeps the request method. Any other redirect is not followed and the request fails with an error naming the target (MCPError on 2.x, httpx.HTTPStatusError on 1.x), whichever HTTP client the transport uses. The internal create_mcp_http_client helper no longer turns redirect following on, so code calling it directly now receives the redirect response instead.

If your client currently reaches its server through a redirect to another host, including a server that needs no credentials, it will stop connecting after the upgrade: set the endpoint URL to the redirect's target.

Until you can upgrade, supply your own HTTP client with follow_redirects left at False (http_client= on streamable_http_client; httpx_client_factory= on sse_client and streamablehttp_client; ClientSessionGroup has no such parameter). If a client may already have followed a redirect to a host you do not control, rotate the credentials it carried.

If you genuinely need the old behaviour (unsupported)

This restores what this advisory fixes: redirects to any host are followed again, carrying your custom headers and, on 307/308, the request body, OAuth token requests included. Prefer setting the endpoint URL to the redirect's target. If you cannot, and you accept forwarding credentials to the redirect target, give the transport an HTTP client that follows redirects regardless of what the SDK asks for:

import httpx2  # on 1.x: import httpx and subclass httpx.AsyncClient instead

class FollowRedirectsAnyway(httpx2.AsyncClient):
    """Follows redirects to ANY origin. Deliberately gives up the SDK's same-origin protection."""

    async def send(self, request, *, follow_redirects=False, **kwargs):
        return await super().send(request, follow_redirects=True, **kwargs)

http_client = FollowRedirectsAnyway(timeout=httpx2.Timeout(30, read=300))

##### streamable_http_client(url, http_client=http_client)

##### sse_client / streamablehttp_client take a factory instead:
def client_factory(headers=None, timeout=None, auth=None):
    return FollowRedirectsAnyway(headers=headers, auth=auth,
                                 timeout=timeout if timeout is not None else httpx2.Timeout(30, read=300))

##### sse_client(url, httpx_client_factory=client_factory)

The redirect handling is then the HTTP library's own, as before the fix: a lone Authorization header is still dropped on cross-origin hops and 301/302/303 become GET. It is not something the SDK supports or tests.

Severity

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

References

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

MCP Python SDK: Unbounded Session Accumulation in StreamableHTTP Transport Enables Resource Exhaustion

CVE-2026-59951 / GHSA-84m7-p3x7-pcfv

More information

Details

Summary

In affected versions, a Streamable HTTP server in stateful mode (the default) never reclaimed session state:

  • sessions did not expire;
  • a client DELETE ended the session but left its entry registered;
  • a session whose first request was refused stayed registered with a running task.

Each session also kept its parsed initialize parameters, and the number of sessions was unlimited. A client that could reach the endpoint could grow server memory without bound using ordinary short requests; only a restart reclaimed it.

Am I affected?

Yes, if you serve MCP over Streamable HTTP in stateful mode and clients you do not fully trust can reach the endpoint. Stateful mode is the default for:

  • FastMCP (1.x)
  • MCPServer and Server.streamable_http_app() (2.x)
  • StreamableHTTPSessionManager

Affected versions: 1.8.0 through 1.29.1, and 2.0.0 through 2.1.1.

Not affected:

  • servers on 1.12.0 or later passing stateless_http=True (no sessions are kept)
  • servers using only the stdio or SSE transports

Authentication limits who can open sessions, not how many a token holder can open.

Fix

Upgrade to mcp 1.30.0 (1.x) or 2.2.0 (2.x) or later. In those versions:

  • a session with no request in flight for session_idle_timeout seconds (default 1800) is closed and its ID then answers 404; open streams and in-progress requests keep it alive;
  • at most max_sessions sessions exist at once (default 10000); a request that would open another is answered 503;
  • a session is discarded as soon as it ends, whether by DELETE, expiry, or a refused opening request.

Both settings are keyword arguments on FastMCP(...) (1.x), MCPServer.run() / streamable_http_app() (2.x) and StreamableHTTPSessionManager; None disables them.

This bounds retention rather than eliminating it: a live session still holds its initialize parameters (up to roughly twice the 4 MiB body limit), and an initialize with invalid parameters still opens a session that expires like any other. On a small host, lower session_idle_timeout, max_sessions and max_request_body_size to fit.

If you cannot upgrade yet, pass stateless_http=True (1.12.0 or later) where you need no per-session state, or restrict who can reach the endpoint.

Severity

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

References

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

Model Context Protocol Python SDK: Client fetched server-chosen $ref URLs while validating tool results against output schemas

CVE-2026-116686 / GHSA-rwrf-2pqf-9j8j

More information

Details

Summary

In affected versions, when a connected MCP server declared an outputSchema for a tool, the SDK's client validated each call_tool result with jsonschema's default resolver, which fetches any $ref it cannot resolve locally by opening the URL. A server could therefore put an http://, https:// or file:// reference in a tool's output schema and make the client:

  • request that URL, or read that local file, from the client's own network position on every call of the tool (the content was used only as a schema and never sent back to the server), and
  • stall: the fetch ran synchronously on the event loop with no timeout, so a target that accepted the connection and then went quiet froze every session in the process for as long as it held the connection.
Am I affected?

Yes, if your application uses the SDK as an MCP client (ClientSession over any transport, ClientSessionGroup, or the 2.x Client) and calls tools on servers you do not fully control. There was no setting that turned the validation off.

Affected versions: 1.10.0 through 1.29.1, and 2.0.0 through 2.1.1.

Not affected: applications that only build servers. If nothing in your code uses ClientSession, ClientSessionGroup or the 2.x Client class, you are not affected.

Fix

Upgrade to mcp 1.30.0 (1.x) or 2.2.0 (2.x) or later. The client now resolves references only within the schema document the server sent (plus the standard JSON Schema metaschemas), so result validation performs no network or file access. A tool whose output schema points outside its own document fails at call time with RuntimeError (Invalid schema for tool ...); in-document references such as #/$defs/... work as before.

Until you can upgrade, call tools only on servers you trust. As a partial stopgap, skip tools whose outputSchema contains an $id, or a $ref / $dynamicRef that does not start with #.

Severity

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

References

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

Model Context Protocol Python SDK: Server bearer-token authentication accepts tokens issued for a different resource server

CVE-2026-116684 / GHSA-w4fh-qvv9-3v23

More information

Details

Summary

In affected versions, the SDK's server-side bearer authentication had no way to check that a token was issued for your server (its audience). Where one authorization server issues tokens for several services, a valid token for another service was also accepted by your MCP server.

Am I affected?

Yes, if your HTTP server uses the SDK's bearer authentication (auth=AuthSettings(...) with token_verifier=), its authorization server also issues tokens for other services, and your TokenVerifier does not check the token's audience (aud) itself.

Affected versions:

  • mcp 1.10.0 through 1.29.1
  • mcp 2.0.0 through 2.1.1
Fix

Upgrade to:

  • 1.x: mcp 1.30.0 or later
  • 2.x: mcp 2.2.0 or later

Upgrading alone changes nothing. The patched versions add a validate_token_resource setting that is off unless you set it. To turn the check on, make both of these changes together:

  1. Set validate_token_resource=True in AuthSettings, with resource_server_url set to the audience your authorization server puts in tokens for your server.
  2. Return the token's audience from verify_token() as AccessToken.resource.

A token for another service then gets 401. With only the first change, every request gets 401.

If your TokenVerifier already checks the audience, set validate_token_resource=False to silence the deprecation warning. The setting will default to True in 3.0.

If you cannot upgrade yet, reject any token whose aud does not include your server inside verify_token(). That closes the issue on every version.

Severity

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

References

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

Release Notes

modelcontextprotocol/python-sdk (mcp)

v1.30.0

Compare Source

Maintenance release of the 1.x line. 2.x is the current line; 1.x docs are at https://py.sdk.modelcontextprotocol.io/v1/.

A few defaults changed in this release. If you run a server or client on 1.x, skim these first:

Behaviour changes

HTTP client redirects are only followed within the endpoint's origin (#​3448)

  • streamable_http_client and sse_client follow a redirect only if it stays on the same scheme, host and port (or upgrades http to https on the same host).
  • A redirect anywhere else now fails the request with httpx.HTTPStatusError. If that other URL is the server you meant, use it as the endpoint URL.
  • The follow_redirects setting on an httpx.AsyncClient you pass in is no longer used for MCP requests, so you don't need it for the trailing-slash redirect any more.
  • OAuthClientProvider applies the same rule to its own requests.

Idle Streamable HTTP sessions now expire (#​3426)

  • A stateful session with nothing in flight for 30 minutes is closed. The client's next request gets a 404 and it has to initialize again.
  • Clients that keep the GET stream open (the SDK's client does) are not affected.
  • A server also holds at most 10 000 sessions at once; beyond that, new sessions get a 503.
  • To turn either off: FastMCP(..., session_idle_timeout=None, max_sessions=None).

The OAuth client checks the authorization server's issuer (#​3431)

  • Authorization server metadata whose issuer doesn't match the server it was fetched for is now rejected with OAuthFlowError: Authorization server metadata issuer mismatch.
  • Client registrations are now remembered per issuer; if the server later points at a different authorization server, the client registers again.
  • If protected resource metadata can't be fetched because of a 5xx/429, the flow now stops instead of falling back to the legacy endpoints.

Two new DeprecationWarnings (#​3431, #​3451)

  • ClientCredentialsOAuthProvider / PrivateKeyJWTOAuthProvider without issuer=. Pass your authorization server's issuer URL.
  • AuthSettings with resource_server_url set but validate_token_resource unset. Set it to True or False.
  • Both keep working as before in 1.x; this mostly matters if your tests turn warnings into errors.

New

  • AuthSettings.validate_token_resource: only accept tokens your TokenVerifier reports as issued for this server (#​3451).
  • issuer= on ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider (#​3431).
  • session_idle_timeout= and max_sessions= on FastMCP (#​3426).

What's Changed

  • [v1.x] Resolve tool output-schema references within the schema document only by @​maxisbey in #​3396
  • [v1.x] Expire idle Streamable HTTP sessions by default and cap concurrent sessions by @​maxisbey in #​3426
  • [v1.x] Validate the authorization server metadata issuer on every discovery path by @​maxisbey in #​3431
  • [v1.x] Follow redirects only within the MCP endpoint's origin by @​maxisbey in #​3448
  • [v1.x] Add AuthSettings.validate_token_resource to check a bearer token's resource by @​maxisbey in #​3451

Full Changelog: modelcontextprotocol/python-sdk@v1.29.1...v1.30.0

v1.29.1

Compare Source

What's Changed

Full Changelog: modelcontextprotocol/python-sdk@v1.29.0...v1.29.1

v1.29.0

Compare Source

What's Changed

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

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

[!IMPORTANT]
✂ PR body was truncated to here.

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 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 changed the title chore(deps): update dependency mcp to v1.28.1 [security] chore(deps): update dependency mcp to v1.28.1 [security] - autoclosed Jul 29, 2026
@renovate renovate Bot closed this Jul 29, 2026
@renovate
renovate Bot deleted the renovate/pypi-mcp-vulnerability branch July 29, 2026 05:05
@renovate renovate Bot changed the title chore(deps): update dependency mcp to v1.28.1 [security] - autoclosed chore(deps): update dependency mcp to v1.28.1 [security] Jul 30, 2026
@renovate renovate Bot reopened this Jul 30, 2026
@renovate
renovate Bot force-pushed the renovate/pypi-mcp-vulnerability branch 2 times, most recently from c7d59a0 to 71c5083 Compare July 30, 2026 16:59
@github-project-automation github-project-automation Bot moved this from Done to Dev backlog in Agent Stack Jul 30, 2026
@renovate
renovate Bot force-pushed the renovate/pypi-mcp-vulnerability branch from 71c5083 to db60d1c Compare August 12, 2026 03:43
@renovate
renovate Bot force-pushed the renovate/pypi-mcp-vulnerability branch from db60d1c to cf987e3 Compare August 26, 2026 16:20
@renovate renovate Bot changed the title chore(deps): update dependency mcp to v1.28.1 [security] chore(deps): update dependency mcp to v2 [security] Aug 31, 2026
@renovate renovate Bot changed the title chore(deps): update dependency mcp to v2 [security] chore(deps): update dependency mcp to v1.28.1 [security] Sep 1, 2026
@renovate renovate Bot changed the title chore(deps): update dependency mcp to v1.28.1 [security] chore(deps): update dependency mcp to v2 [security] Sep 3, 2026
@renovate renovate Bot changed the title chore(deps): update dependency mcp to v2 [security] chore(deps): update dependency mcp to v1.28.1 [security] Sep 3, 2026
@renovate renovate Bot changed the title chore(deps): update dependency mcp to v1.28.1 [security] chore(deps): update dependency mcp to v1.28.1 [security] - autoclosed Sep 3, 2026
@renovate renovate Bot closed this Sep 3, 2026
@github-project-automation github-project-automation Bot moved this from Dev backlog to Done in Agent Stack Sep 3, 2026
@renovate renovate Bot changed the title chore(deps): update dependency mcp to v1.28.1 [security] - autoclosed chore(deps): update dependency mcp to v1.28.1 [security] Sep 4, 2026
@renovate renovate Bot reopened this Sep 4, 2026
@renovate
renovate Bot force-pushed the renovate/pypi-mcp-vulnerability branch from fa2b525 to cf987e3 Compare September 4, 2026 01:49
@github-project-automation github-project-automation Bot moved this from Done to Dev backlog in Agent Stack Sep 4, 2026
@renovate
renovate Bot force-pushed the renovate/pypi-mcp-vulnerability branch 2 times, most recently from fa2b525 to 1005763 Compare September 7, 2026 22:14
@renovate renovate Bot changed the title chore(deps): update dependency mcp to v1.28.1 [security] chore(deps): update dependency mcp to v2 [security] Sep 8, 2026
@renovate renovate Bot changed the title chore(deps): update dependency mcp to v2 [security] chore(deps): update dependency mcp to v1.28.1 [security] Sep 8, 2026
@renovate
renovate Bot force-pushed the renovate/pypi-mcp-vulnerability branch from 1005763 to b173c0a Compare September 15, 2026 20:43
@renovate
renovate Bot force-pushed the renovate/pypi-mcp-vulnerability branch from b173c0a to f77be20 Compare September 25, 2026 03:45
@renovate
renovate Bot force-pushed the renovate/pypi-mcp-vulnerability branch from f77be20 to 1440e53 Compare October 13, 2026 14:06
@renovate renovate Bot changed the title chore(deps): update dependency mcp to v1.28.1 [security] chore(deps): update dependency mcp to v1.30.0 [security] Oct 16, 2026
@renovate
renovate Bot force-pushed the renovate/pypi-mcp-vulnerability branch from 1440e53 to 2ad1f65 Compare October 20, 2026 15:52
@renovate
renovate Bot force-pushed the renovate/pypi-mcp-vulnerability branch from 2ad1f65 to 44de75d Compare October 26, 2026 20:10

This branch has not been deployed

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

Agent Stack
Status: Dev backlog

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants