CVE-2026-116685

The Model Context Protocol Python SDK is the official Python SDK for Model Context Protocol servers and clients. From 1.8.0 until 1.30.0 and 2.2.0, streamable_http_client, streamablehttp_client, sse_client, ClientSessionGroup, OAuth, and create_mcp_http_client client paths enable follow_redirects and follow redirects to a different origin, forwarding caller-supplied custom credential headers and, for 307 or 308 responses, the request body. An attacker who can influence a trusted endpoint's redirect destination can receive that material. This issue is fixed in versions 1.30.0 and 2.2.0.

The Model Context Protocol Python SDK is the official Python SDK for Model Context Protocol servers and clients. From 1.8.0 until 1.30.0 and 2.2.0, streamable_http_client, streamablehttp_client, sse_client, ClientSessionGroup, OAuth, and create_mcp_http_client client paths enable follow_redirects and follow redirects to a different origin, forwarding caller-supplied custom credential headers and, for 307 or 308 responses, the request body. An attacker who can influence a trusted endpoint's redirect destination can receive that material. This issue is fixed in versions 1.30.0 and 2.2.0.

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.

<details> <summary>If you genuinely need the old behaviour (unsupported)</summary>

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

The Model Context Protocol Python SDK is the official Python SDK for Model Context Protocol servers and clients. From 1.8.0 until 1.30.0 and 2.2.0, streamable_http_client, streamablehttp_client, sse_client, ClientSessionGroup, OAuth, and create_mcp_http_client client paths enable follow_redirects and follow redirects to a different origin, forwarding caller-supplied custom credential headers and, for 307 or 308 responses, the request body. An attacker who can influence a trusted endpoint's redirect destination can receive that material. This issue is fixed in versions 1.30.0 and 2.2.0.

The Model Context Protocol Python SDK is the official Python SDK for Model Context Protocol servers and clients. From 1.8.0 until 1.30.0 and 2.2.0, streamable_http_client, streamablehttp_client, sse_client, ClientSessionGroup, OAuth, and create_mcp_http_client client paths enable follow_redirects and follow redirects to a different origin, forwarding caller-supplied custom credential headers and, for 307 or 308 responses, the request body. An attacker who can influence a trusted endpoint's redirect destination can receive that material. This issue is fixed in versions 1.30.0 and 2.2.0.

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.

<details> <summary>If you genuinely need the old behaviour (unsupported)</summary>

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