GHSA-9g45-5xwm-f3wc: Infoleak

Summary

The rmcp crate's StreamableHttpClientTransport forwards caller-supplied custom HTTP headers (such as X-API-Key, X-Auth-Token, Api-Key) to cross-origin redirect targets. The defaulthttpclient() function builds a reqwest::Client without a redirect policy override, so the default limited(10) policy follows 307/308 redirects and forwards all per-request headers except Authorization, Cookie, and Proxy-Authorization. Custom auth headers injected via StreamableHttpClientTransportConfig.customheaders are not classified as sensitive and are therefore forwarded verbatim to any redirect target — including an attacker-controlled server.

Affected versions

- Repository: github.com/modelcontextprotocol/rust-sdk - Crate: rmcp - Commit tested: c330fede90e4729c234f8e87fdbc5ea27a1dd10c (HEAD, 2026-05-21)

Vulnerability

File: crates/rmcp/src/transport/common/reqwest/streamablehttpclient.rs

Root cause 1 — no redirect policy override:

rust // Lines 302-307 fn defaulthttpclient() -> reqwest::Client { reqwest::Client::builder() .poolmaxidleperhost(0) .build() .expect("failed to build default reqwest client") }

No .redirect(reqwest::redirect::Policy::none()) call. The default limited(10) policy follows up to 10 redirects and, on cross-origin redirects, strips only Authorization, Cookie, and Proxy-Authorization.

Root cause 2 — custom headers not sensitivity-marked:

rust // Lines 26-35 fn applycustomheaders( mut builder: reqwest::RequestBuilder, customheaders: HashMap<HeaderName, HeaderValue>, ) -> Result<reqwest::RequestBuilder, StreamableHttpError<reqwest::Error>> { for (name, value) in customheaders { validatecustomheader(&name).maperr(StreamableHttpError::ReservedHeaderConflict)?; builder = builder.header(name, value); // no sensitivity marker } Ok(builder) }

Headers added via RequestBuilder::header() are forwarded to redirect targets because reqwest only strips headers from its own sensitive-header list (Authorization, Cookie, Proxy-Authorization).

Exposed API: StreamableHttpClientTransportConfig.customheaders (line 1070), intended for custom auth headers:

rust /// Custom HTTP headers to include with every request pub customheaders: HashMap<HeaderName, HeaderValue>,

Attack scenario

1. A caller sets customheaders with an API key for the MCP server: rust let config = StreamableHttpClientTransportConfig::withuri("https://mcp.example.com/mcp") .customheaders([(HeaderName::fromstatic("x-api-key"), HeaderValue::fromstatic("my-secret-key"))].into()); 2. An attacker compromises mcp.example.com to return 307 Temporary Redirect to https://attacker.example.net/capture. 3. rmcp follows the redirect, forwarding X-API-Key: my-secret-key to attacker.example.net. 4. The attacker captures the secret and reuses it to call the MCP server directly.

Negative control

The authheader path (StreamableHttpClientTransportConfig::authheader()) sets the value via builder.bearerauth(authheader), which maps to the Authorization header — stripped by reqwest on cross-origin redirects. That path is not affected. Only customheaders is vulnerable.

Fix

In defaulthttpclient(), disable automatic redirect following:

rust fn defaulthttpclient() -> reqwest::Client { reqwest::Client::builder() .poolmaxidleperhost(0) .redirect(reqwest::redirect::Policy::none()) // <-- add this .build() .expect("failed to build default reqwest client") }

The transport can then inspect 3xx responses and decide whether to follow, stripping sensitive headers before doing so. Alternatively, use reqwest::ClientBuilder::connectionverbose or per-request Request::headersmut() to remove auth headers before the redirect is followed.