Server-Side Request Forgery (SSRF) in MCP

Server-side request forgery (SSRF) in MCP is when an attacker tricks an MCP client or server into fetching a URL it should never touch. The target is usually something inside your network, such as an admin panel, a database, or a cloud metadata service that hands out credentials.

The MCP specification treats this as a real threat. Its Security Best Practices page has a full SSRF section. It explains how a malicious server can plant internal URLs in OAuth metadata that a client then follows.

This page explains the attack in plain English, who is exposed, how to spot it, and what to change. Sources were checked on 28 October 2026, and the advice reflects the 2026-07-28 spec, the latest version as of October 2026.

What SSRF looks like in MCP

A normal web app SSRF bug lets a user submit a URL that the server fetches. MCP adds new places where URLs arrive from untrusted parties.

The spec lists three during OAuth metadata discovery. A client reads the resource_metadata URL from a WWW-Authenticate header. It reads authorization_servers from the Protected Resource Metadata document. It then reads the token_endpoint, authorization_endpoint and similar URLs from Authorization Server Metadata.

A malicious MCP server controls all of these. According to the best practices page, it can fill them with internal IP addresses or http://169.254.169.254/ cloud metadata URLs. It can also use localhost services, DNS rebinding domains, or redirect chains.

Tools are the second route. Any tool that accepts a URL argument, such as a "fetch this page" tool, can be pointed at an internal address by a prompt-injected model. Our guide to prompt injection through tool results covers how that steering happens.

Authorization servers are the third. The spec notes that a server supporting Client ID Metadata Documents "takes a URL as input from an unknown client and fetches that URL." That makes the authorization server itself an SSRF target.

An illustrative example

This scenario is illustrative, not a real incident.

A company runs a hosted AI assistant on a cloud virtual machine. Staff can add MCP servers by URL. Someone adds a server that looks like a free analytics tool.

When the assistant connects, the server replies 401 with a resource_metadata value pointing at the cloud metadata address. The assistant's MCP client follows it without checks. The metadata service returns temporary cloud credentials. An error message containing part of that response flows back to the malicious server on the next request.

No one clicked anything unusual. The client did exactly what the metadata told it to do.

Real advisories that show the pattern

These are published advisories. Each was opened on 28 October 2026.

The n8n-mcp case matches a warning in the spec almost word for word. The spec says to "avoid implementing IP validation manually" because attackers use "octal, hex, IPv4-mapped IPv6" tricks.

Who is at risk

• Server-side MCP clients. Hosted agents, chat platforms and gateways running in the cloud are the main target. They often sit next to metadata services and private networks.
• Servers with URL-taking tools. Fetchers, crawlers, webhook testers and API connectors that accept a base URL.
• Authorization servers that accept Client ID Metadata Documents. They fetch URLs supplied by unknown clients.
• Desktop users, to a lesser degree. A laptop client can still reach home routers and local services, but there is usually no cloud metadata to steal.

How to detect it

• Log every outbound request your MCP client or server makes, with the destination IP after DNS resolution.
• Alert on any request to 169.254.169.254, 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16 from an MCP process.
• Watch for OAuth discovery that points at a different domain than the MCP server you connected to.
• Review error messages that return to servers. The spec notes that internal responses can leak "through error messages or OAuth flows."

Our MCP audit logging guide covers what to record.

How to reduce the risk

Client side

The best practices page sets out these controls:

1. Enforce HTTPS. Clients SHOULD reject http:// OAuth URLs except loopback addresses during development.
2. Block private and reserved IP ranges. The spec lists private IPv4, loopback, link-local 169.254.0.0/16, and private IPv6 fc00::/7 and fe80::/10.
3. Validate every redirect hop. Consider turning off automatic redirect following and checking each destination.
4. Pin DNS results. A domain can resolve to a safe IP during your check and an internal IP during the request. Pin the result between check and use.
5. Use a tested library. Do not write your own IP parser.

Server side

• Treat every URL argument as untrusted input. The tools spec says servers MUST "validate all tool inputs."
• Never forward user credentials to a URL the caller chose. The n8n-mcp advisory shows how an API key can follow the request.
• If you run an authorization server that fetches client metadata, apply the same IP blocking. The authorization security considerations say it SHOULD consider SSRF risks.

Organization side

• Route MCP egress through a proxy that blocks internal destinations. The spec names Stripe's Smokescreen as one example.
• Use cloud metadata protections your provider offers, so a stray request cannot pull credentials.
• Keep MCP workloads on a network segment that cannot reach admin panels or databases they do not need.

What the spec says

The SSRF section of the 2026-07-28 best practices is direct. "MCP clients deployed to a server MUST consider SSRF risks and implement appropriate mitigations when fetching OAuth-related URLs." The specific controls (HTTPS, IP blocking, redirect checks, egress proxies) are SHOULD-level. The spec adds that the right mix depends on your network.

SSRF is related to two other threats on this site. DNS rebinding is one way attackers beat IP checks. Common MCP OAuth misconfigurations covers the rest of the discovery flow.

Next step

If you run a hosted agent or gateway, check its egress rules first. Our MCP readiness audit reviews outbound network paths, URL-taking tools and OAuth discovery handling. For more threats, browse the MCP Security Center.

Frequently asked questions