MCP server SSRF security: Server-Side Request Forgery in tools that make HTTP calls
Server-Side Request Forgery (SSRF) occurs when an application makes an HTTP request to a URL that is partially or fully controlled by an attacker. MCP servers are particularly vulnerable because "fetch a URL and return its content" is a common, useful tool — and the URL argument is attacker-controlled. In cloud environments, SSRF is often a critical vulnerability because it provides access to instance metadata services that contain temporary cloud credentials.
The SSRF attack surface in MCP tools
MCP tools that commonly introduce SSRF: fetch_url / web_search tools that retrieve web pages, webhook_send tools that POST to a caller-provided endpoint, tools that load external resources (images, documents) from URLs, and any tool that accepts a URL or hostname as an argument and makes an outbound connection. The threat model: the caller supplies a URL that resolves to an internal or cloud-infrastructure address, causing the MCP server to make a request from its network context (which has internal network access) and return the response.
The AWS IMDS attack (and its equivalents)
On AWS EC2 instances, http://169.254.169.254/latest/meta-data/iam/security-credentials/ returns temporary IAM credentials for the instance role — no authentication required, only network access from the EC2 instance. An MCP server that fetches caller-supplied URLs and returns the response will happily fetch this endpoint and return the credentials to the attacker. Equivalent endpoints exist on GCP (http://metadata.google.internal/computeMetadata/v1/), Azure (http://169.254.169.254/metadata/instance), and DigitalOcean. These endpoints are the primary SSRF impact in cloud deployments — credential theft leading to full cloud account compromise.
IMDSv2 on AWS requires a token fetch step before the metadata request, which mitigates SSRF from simple GET requests. But not all MCP servers run on IMDSv2-enabled instances, and the Kubernetes metadata API (http://10.96.0.1/) has no equivalent protection.
DNS rebinding as an SSRF bypass
Allowlisting external URLs by checking for internal IP ranges at request time is bypassed by DNS rebinding: a DNS record initially resolves to an external IP (passing the check), then re-resolves to an internal IP when the actual HTTP connection is made. The fix for DNS rebinding: resolve the URL's hostname to an IP before making the request, check that the resolved IP is not in a private or link-local range, and use that resolved IP for the connection (pinning the DNS resolution). Many HTTP client libraries do not do this by default.
URL validation that works
A URL allowlist that blocks SSRF: (1) parse the URL with your language's URL parsing library, (2) resolve the hostname to one or more IP addresses, (3) reject any resolved IP in 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 169.254.0.0/16 (link-local/IMDS range), 100.64.0.0/10 (shared address space), ::1 and fc00::/7 (IPv6 loopback and ULA), (4) connect to the resolved IP directly rather than re-resolving the hostname for the HTTP request. Steps 1-3 without step 4 are vulnerable to DNS rebinding.
If your tool's use case allows it, prefer a domain allowlist over a blocklist: define the set of external domains the tool is permitted to reach, and reject all others. This is far more restrictive and eliminates entire classes of bypass.
What SkillAudit checks for SSRF
SkillAudit's Security axis flags SSRF-related patterns in MCP server source:
- Tool handlers that call
fetch(),axios.get(),requests.get()with an argument sourced from tool input — flags HIGH (SSRF if no URL validation present) - IP range validation without DNS resolution pinning — flags HIGH (DNS rebinding bypass)
- URL arguments with no hostname/IP validation — flags CRITICAL
- Outbound HTTP calls to localhost or 127.0.0.1 in code paths reachable from tool arguments — flags CRITICAL
- Missing IMDSv2 token requirement in AWS deployment configurations — flags MEDIUM (cloud-specific SSRF impact)