Skip to content

fix: add DNS-level SSRF protection to MCP endpoints#2195

Open
rtrompier wants to merge 2 commits intomainfrom
fix/mcp-ssrf-dns-rebinding
Open

fix: add DNS-level SSRF protection to MCP endpoints#2195
rtrompier wants to merge 2 commits intomainfrom
fix/mcp-ssrf-dns-rebinding

Conversation

@rtrompier
Copy link
Contributor

Summary

  • MCP endpoints (health check, tool listing, client pool) only validated URLs at the hostname string level via isValidUrl(), which doesn't catch DNS rebinding attacks (e.g. a domain resolving to 169.254.169.254 for cloud metadata theft)
  • Added a shared ssrfSafeFetch wrapper in urlSafety.ts using undici with a custom DNS lookup callback that validates resolved IPs at connection time — same pattern already used by fetch-url
  • Applied to all MCP SDK transport instantiations (StreamableHTTPClientTransport and SSEClientTransport) across health, tools, and clientPool

Reported via HackerOne #31963.

The MCP health, tools, and client pool endpoints only validated URLs
at the hostname string level (isValidUrl), allowing DNS rebinding
attacks to reach internal services (e.g. cloud metadata at
169.254.169.254).

Add a shared ssrfSafeFetch wrapper using undici with a custom DNS
lookup callback that validates resolved IPs at connection time,
matching the existing protection in fetch-url. Apply it to all MCP
SDK transport instantiations.
Replace the inline undici Agent in fetch-url with the shared
ssrfSafeFetch wrapper from urlSafety.ts, removing ~30 lines of
duplicated DNS lookup validation code.
@rtrompier rtrompier requested a review from gary149 March 19, 2026 13:39
@rtrompier rtrompier marked this pull request as ready for review March 19, 2026 13:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant