zeph-mcp HTTP transport: SSRF guard has a DNS-rebinding TOCTOU gap (same defect class as #5380, fix not applied here)

[bug-ops]

Description

zeph-mcp's HTTP transport connection paths validate the target URL for SSRF via validate_url_ssrf() (crates/zeph-mcp/src/client.rs:1148-1179), which resolves the hostname with tokio::net::lookup_host and rejects private/loopback/link-local IPs. This check is a standalone pre-flight lookup — its result (the validated SocketAddrs) is discarded, and the actual connection is established moments later using the same hostname string, via a code path that performs its own independent DNS resolution:

• connect_url() (client.rs:488-526): validate_url_ssrf(url) at line 498, then StreamableHttpClientTransport::from_uri(url.to_owned()) at line 501 — the transport's internal HTTP client re-resolves the hostname itself.
• connect_url_with_headers() (client.rs:545-610): validate_url_ssrf(url) at line 556, then StreamableHttpClientTransportConfig::with_uri(url) + StreamableHttpClientTransport::with_client(reqwest::Client::default(), config) at lines 582-585 — a bare default reqwest::Client with no resolve_to_addrs pinning and no hardened redirect policy.
• connect_url_oauth() (client.rs:630-...): validate_url_ssrf(url) at line 644, then (cached-token path) AuthClient::new(reqwest::Client::default(), manager) + StreamableHttpClientTransportConfig::with_uri(url) at lines 677-680 — same pattern.

An attacker who controls DNS for the target hostname (a dynamically-added MCP server via /mcp add, or a plugin-declared [[mcp.servers]] entry installed from the marketplace — the exact case trusted: bool is false for, per issue #1441) can return a public IP for the validate_url_ssrf lookup (passing the check) and then switch the DNS record to a private/internal address (e.g. 127.0.0.1, a cloud metadata endpoint 169.254.169.254) before the transport's own, later, independent DNS resolution — bypassing the SSRF guard entirely via classic DNS rebinding. with_client(reqwest::Client::default(), ...) additionally has reqwest's default redirect policy (follows up to 10 redirects, any host), so even a same-instant race is unnecessary: a malicious MCP server can simply 3xx-redirect the initial (validated) request toward an internal address.

This is the same defect class already fixed elsewhere in this codebase, but missed in zeph-mcp

Issue #5380 (a2a client: ssrf_protection has a DNS-rebinding TOCTOU gap and is never enabled in production) described and PR #5389 fixed the identical pattern in zeph-a2a's client and zeph-tools/scrape.rs:

• extracted a shared zeph_common::net::resolve_and_validate(host, port) -> Vec<SocketAddr> helper (crates/zeph-common/src/net.rs:139-157) that performs the one authoritative resolution,
• pins the actual HTTP client to those exact addresses via reqwest::ClientBuilder::resolve_to_addrs(host, addrs) so the connect-time resolver cannot diverge from the validated one,
• and hardens the redirect policy (Policy::none() plus https_only when TLS is required) so a redirect response cannot route the connection to an unvalidated host.

zeph-mcp already depends on zeph-common (crates/zeph-mcp/Cargo.toml:48), so resolve_and_validate is available for reuse without a new dependency — this was simply not included in PR #5389's fix, which touched only zeph-a2a, zeph-common, and zeph-tools/scrape.rs.

Reproduction

1. Add a dynamic (non-config, trusted=false) MCP HTTP server pointing at an attacker-controlled hostname with a very short DNS TTL.
2. First resolution (during validate_url_ssrf) returns a public IP — check passes.
3. Flip the DNS record to 127.0.0.1 (or an internal/metadata address) before/while the transport performs its own connection-time resolution.
4. The MCP handshake proceeds against the internal address; validate_url_ssrf's check is bypassed.
   (Redirect variant: point the initial public-IP response at a 3xx redirect to http://127.0.0.1/... — reqwest::Client::default()'s redirect policy follows it with no re-validation.)

Expected Behavior

Mirror the zeph-a2a/zeph-tools fix: resolve once via zeph_common::net::resolve_and_validate, pin the reqwest::Client used by StreamableHttpClientTransport::with_client to those addresses via .resolve_to_addrs(host, &addrs), and set a redirect policy that either disables redirects or re-validates the target before following.

Actual Behavior

SSRF validation and the actual network connection are decoupled, independent DNS resolutions — the validated address is never enforced at connect time, and default redirect-following applies no re-validation.

Environment

• Version/commit: 03e162f (HEAD at CI cycle 1356, 2026-07-11)
• Features: default (MCP client is always compiled; HTTP transport used when [[mcp.servers]] url or /mcp add <url> is configured)

Spec

No existing /specs/ entry covers MCP client SSRF posture specifically; specs/014-a2a/spec.md's "Client Security Posture" section (added by PR #5389) is the closest precedent and should be mirrored for zeph-mcp alongside the fix.

Related

• Closes-class sibling: a2a client: ssrf_protection has a DNS-rebinding TOCTOU gap and is never enabled in production #5380 (same defect in zeph-a2a, fixed by PR fix(a2a): close SSRF DNS-rebinding TOCTOU and redirect bypass, replace boolean-blind with_security #5389)
• MCP HTTP transport: SSRF guard blocks localhost for statically configured servers #1441 (established the trusted: bool skip-SSRF-for-config-servers design that makes the dynamic/plugin-declared path the actual attack surface here)

[bug-ops]

Live corroboration: source-level proof + working exploit reproduction

Following up on the analysis above with concrete verification (per explicit authorization to publish full detail).

1. Source-level proof the two DNS resolutions are genuinely independent

Traced into vendored rmcp v2.0.0's StreamableHttpClientTransport::from_uri/default_http_client() (rmcp-2.0.0/src/transport/common/reqwest/streamable_http_client.rs:277-307): it builds a fresh reqwest::Client with no resolve_to_addrs pinning and no redirect-policy override. This confirms validate_url_ssrf()'s tokio::net::lookup_host result and the transport's own later resolution are genuinely two independent DNS lookups — not just an inferred gap from reading zeph-mcp's code alone.

2. Live exploit reproduction (redirect-bypass variant — no DNS control needed)

Built a standalone repro outside the zeph repo (own Cargo.toml, reqwest 0.13.4 — the same pinned version zeph-mcp uses) reusing the exact vulnerable construction from connect_url_with_headers (reqwest::Client::default()). Pointed it at a local server returning a 302 redirect to http://127.0.0.1:<port>/.

Result: the client silently followed the redirect and returned the private target's response body. This proves the bypass is practically exploitable today via a single malicious HTTP response — DNS rebinding (requiring TTL timing) is a second, independent trigger of the same root cause (no post-validation address pinning), not the only way to exploit it. A malicious/compromised MCP server operator does not need to race DNS at all; a bare 3xx response against the already-validated hostname is sufficient.

3. Remediation cross-check against PR #5389

gh pr view 5389 --json files confirms the fix shape proposed above matches PR #5389 exactly:

• zeph-common/src/net.rs (+87 lines): resolve_and_validate/is_private_ip/is_loopback_host
• zeph-a2a/src/client.rs (+351/-66): resolve_to_addrs pinning + redirect(Policy::none())
• zeph-tools/src/scrape.rs (+20/-17): same helpers reused

No adjustment needed to the fix design already proposed on this issue — it is a direct, mechanical port of an already-shipped, already-tested pattern.

4. Related: the same defect class also affects the OAuth flow (separate from this issue's HTTP-transport scope)

connect_url_oauth's OAuth traffic (metadata discovery, dynamic client registration, token exchange) is issued by rmcp::transport::auth::AuthorizationManager's own internally-constructed reqwest::Client (AuthorizationManager::new, rmcp-2.0.0/src/transport/auth.rs:954-964) — a client zeph-mcp never controls or pins, independent of this issue's connect_url/connect_url_with_headers paths. validate_oauth_metadata_urls (oauth.rs:165-210) does the same standalone pre-check on the discovered endpoints (token_endpoint, authorization_endpoint, jwks_uri, registration_endpoint) but the actual OAuth HTTP calls bypass it the same way. rmcp already exposes the fix hook: AuthorizationManager::new_with_oauth_http_client (auth.rs:968-973, takes a custom Arc<dyn OAuthHttpClient>) — zeph-mcp's OAuthState::new(url, None) (client.rs:648) never uses it. One partial mitigation: AuthorizationManager::new() defaults OAuthHttpRedirectPolicy::Stop, so the redirect-bypass variant demonstrated above does not apply to the OAuth path — only DNS rebinding does there.

Filing this OAuth-flow instance as a separate linked issue for tracking, since it needs its own fix (new_with_oauth_http_client + a pinned client) alongside this issue's resolve_and_validate port — recommend both land in the same PR since they share root cause and fix pattern.