CVE-2026-64684: 
Linux Red Hat Analyse et atténuation des vulnérabilités

CVE-2026-64684 is a credential/token disclosure vulnerability in the rmcp crate — the official Rust SDK for the Model Context Protocol (MCP) — where custom HTTP headers (such as API keys and authentication tokens) are leaked to cross-origin redirect targets. The vulnerability affects rmcp versions up to and including 1.7.0 (prior to 2.1.0) and was disclosed on September 16, 2026. The fix was merged on July 1, 2026 and released in version 2.1.0. It carries a CVSS v3.1 base score of 6.8 (Medium) (GitHub Advisory, Red Hat CVE).

The vulnerability has two root causes classified under CWE-212 (Improper Removal of Sensitive Information Before Storage or Transfer) and CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). First, the default_http_client() function in crates/rmcp/src/transport/common/reqwest/streamable_http_client.rs builds a reqwest::Client without overriding the default redirect policy, which follows up to 10 redirects and only strips Authorization, Cookie, and Proxy-Authorization headers on cross-origin redirects. Second, the apply_custom_headers() function injects caller-supplied headers (e.g., X-API-Key, X-Auth-Token) via RequestBuilder::header() without marking them as sensitive, so they are forwarded verbatim to any redirect target — including attacker-controlled servers. The auth_header path using builder.bearer_auth() (which maps to the Authorization header) is not affected, as reqwest strips that header on cross-origin redirects (GitHub Advisory, Fix PR).

Successful exploitation allows an unauthenticated attacker who controls or has compromised an MCP endpoint to capture API keys and authentication tokens by issuing a cross-origin 307 or 308 redirect response. The captured credentials can then be reused to impersonate the victim client and make unauthorized calls to the original MCP server. The confidentiality impact is high (credential exfiltration), while integrity and availability are not directly affected (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure. The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires the attacker to either compromise or control a legitimate MCP endpoint (man-in-the-middle or supply chain position), which raises the attack complexity to High (GitHub Advisory, Red Hat CVE).

1. Identify a target: Locate an application using the rmcp crate (versions ≤ 1.7.0) that configures StreamableHttpClientTransportConfig.custom_headers with API keys or authentication tokens (e.g., X-API-Key, X-Auth-Token).
2. Compromise or control an MCP endpoint: Gain the ability to manipulate HTTP responses from the MCP server the target application connects to — either by compromising the server, performing a MITM attack, or operating a malicious MCP endpoint that the victim connects to.
3. Issue a cross-origin redirect: When the rmcp client sends a request (e.g., a POST to /mcp), respond with an HTTP 307 Temporary Redirect or 308 Permanent Redirect pointing to an attacker-controlled server at a different origin (e.g., https://attacker.example.net/capture).
4. Capture forwarded headers: The rmcp HTTP client automatically follows the redirect and replays all custom headers — including the API key — to the attacker-controlled destination. Collect the credentials from the incoming request logs on the attacker's server.
5. Reuse captured credentials: Use the captured API key or token to authenticate directly against the original MCP server, bypassing the legitimate client (GitHub Advisory).

• Network: Unexpected outbound HTTP requests from the application to unfamiliar or attacker-controlled origins immediately following requests to the configured MCP endpoint; HTTP 307/308 redirect responses from the MCP server pointing to external or unexpected domains.
• Logs: Application or HTTP client logs showing redirect-following behavior (e.g., requests to a second host after an initial MCP request); custom auth headers (e.g., X-API-Key, X-Auth-Token) appearing in requests to non-MCP destinations.
• Behavioral: Unauthorized API calls to the MCP server using valid credentials from unexpected source IPs, suggesting credential reuse after exfiltration.

Upgrade the rmcp crate to version 2.1.0 or later, which disables automatic redirect following in default_http_client() by adding .redirect(reqwest::redirect::Policy::none()) to the reqwest::ClientBuilder. This ensures that 3xx responses are returned to the transport layer for explicit handling rather than being followed automatically. As an interim workaround, restrict network egress from affected systems to only trusted MCP endpoints, and rotate any API keys or authentication tokens that may have been exposed. Callers using the auth_header path (via builder.bearer_auth()) are not affected and do not require immediate action (Fix PR, Release v2.1.0).