MCP Python SDK EUVD-2026-111367

Exploitation requires a victim running the SDK as an MCP HTTP client through one of streamable_http_client, streamablehttp_client, sse_client, ClientSessionGroup with HTTP parameters, the OAuth client providers, or the internal create_mcp_http_client helper, in versions 1.8.0-1.29.1 or 2.0.0-2.1.1 where follow_redirects is enabled (the SDK default in those versions, or a client the caller passed with follow_redirects=True). The client must also set custom credential headers (e.g. X-API-Key), and the attacker must be able to make a trusted endpoint issue a cross-origin redirect to an origin they control (a stale redirect to a lapsed domain, a misrouted proxy rule, or attacker-influenced redirect logic). Clear LIMITING factors stated by the vendor: a lone Authorization bearer header is NOT exposed (httpx drops it on cross-origin redirects); the request body is only re-sent on 307/308 responses; MCP servers, stdio clients, and clients supplied with follow_redirects left at its default False are NOT affected; and a malicious MCP server gains nothing since it already receives the client's requests directly.

This is a genuine but conditional credential-disclosure issue (CVSS 5.9, Medium), not a drop-everything emergency. The CVSS vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N is internally consistent with the mechanism: network-reachable (AV:N), no authentication on the victim client side (PR:N), no user interaction (UI:N), and high confidentiality impact (C:H) with no integrity or availability impact (I:N/A:N). The AC:H is justified - exploitation is gated on an attacker's ability to make a trusted endpoint redirect to an origin they control, a precondition outside the attacker's direct control. There is no EPSS score or SSVC decision framework in the supplied data, and the vulnerability is NOT in CISA KEV, so there is no public evidence of active exploitation. The vuln.today priority is 'this_month', consistent with a Medium-severity, patch-available issue rather than an urgent one. The references are the GHSA advisory, fix PRs, commits and release tags - these are remediation artifacts, not exploit code, so no public exploit is identified. Net: a real issue worth patching on a normal cadence for anyone running affected MCP HTTP client code, but its impact is bounded to deployments that both carry custom credential headers and trust an endpoint whose redirect target can be influenced.

An organization runs an MCP client built on the affected SDK, configured with a custom credential header such as X-API-Key to reach a trusted MCP server over HTTP. That server (or a proxy in front of it) is made to issue a cross-origin redirect - for example a stale redirect pointing at a lapsed domain an attacker has since registered - and the client dutifully follows it, forwarding the X-API-Key header (and, on a 307/308, the full request body) to the attacker-controlled origin, who captures the credential. No public exploit code is identified at time of analysis; exploitation also depends on the attacker-controllable redirect precondition rather than a direct flaw the attacker can trigger unaided.