A malicious MCP server can make a client fetch internal URLs during OAuth discovery, including cloud metadata endpoints. The defenses are to require HTTPS, block private and link-local address ranges, validate every redirect, and route server side clients through an egress proxy.
Where the hostile URLs come from
During OAuth metadata discovery, an MCP client fetches URLs it did not choose. The MCP security best practices name three sources: the resource_metadata URL in the WWW-Authenticate header, the authorization_servers URLs in the protected resource metadata, and the token and authorization endpoints in the authorization server metadata.
A hostile server can fill any of these with an address like a private IP, a localhost service or the cloud metadata address. The client then makes the request from inside your network.
What the attacker gets
The specification lists the risks plainly:
- Credential exfiltration, because metadata endpoints often expose IAM credentials.
- Internal reconnaissance, because error messages reveal topology.
- Service interaction, because POST requests to token endpoints can trigger changes.
- Firewall bypass, because the client acts as a proxy.
The specification asks clients that are deployed on a server to consider this risk explicitly.
The listed defenses
Enforce HTTPS for OAuth URLs in production, and allow plain HTTP only for loopback during development.
Block private ranges: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, loopback, and the link-local range 169.254.0.0/16 that includes the metadata address. Block the private IPv6 ranges too.
Validate redirect targets with the same rules. Consider turning off automatic redirects and checking each hop.
Use an egress proxy that enforces network policy for server side deployments. The specification names Smokescreen as an example of a tool built to prevent SSRF.
Watch for DNS rebinding. A domain can resolve to a safe address during validation and an internal one during the request, so consider pinning the resolution result between check and use.
One warning worth repeating
The specification advises against writing your own IP validation. Attackers use encoding tricks such as octal, hex and IPv4 mapped IPv6 forms that hand written parsers often miss. Use a maintained library or a proxy.
A short test plan
- Stand up a test MCP server that returns a metadata URL pointing at a local listener you control.
- Confirm your client refuses to fetch it.
- Repeat with a redirect from a public looking address to the local listener.
- Repeat with a hostname that you flip between a public and a private address.
Where Safeguard fits
Safeguard includes an MCP Guardrail and a dependency scanner. The scanner can help you check which MCP client libraries you ship, but SSRF handling is your application's job.
Quick check
Is HTTPS enough to stop MCP client SSRF?
No. An attacker can serve an internal address over HTTPS, and redirects or DNS rebinding can still lead to internal targets. Combine HTTPS with address blocking, redirect checks and an egress proxy.
Sources
Last reviewed: 19 October 2026.
