There is a four-step chain that turns an unremarkable MCP server feature into cloud account compromise. It relies on nothing exotic. It relies on a server that fetches a URL supplied by whoever is on the other end.
The chain, step by step
First, the MCP server exposes a tool that accepts a URL — convert a document, fetch a page, read a feed. Second, it performs the request server-side without validating the destination. Third, it runs on a cloud instance that can reach the provider's metadata endpoint. Fourth, someone points the tool at that endpoint and receives temporary IAM credentials.
This is not hypothetical. BlueRock Security analysed over 7,000 MCP servers and found roughly 36.7% potentially vulnerable to SSRF. In their proof of concept against Microsoft's MarkItDown MCP server, researchers pulled AWS access keys, secret keys and session tokens from an EC2 instance metadata endpoint.
A misconfigured server became a direct path to cloud infrastructure credentials.
Note what did not happen: no authentication bypass, no zero-day, no manipulation of the model. SSRF entered the OWASP Top 10 in 2021 and was well understood long before that. The component is from 2025; the flaw is timeless.
Why cloud makes it worse
On a traditional server, SSRF gets you access to internal services — bad, but bounded. On a cloud instance, the metadata endpoint is an unauthenticated HTTP service, reachable from any process on the machine, that hands out credentials for the attached role. That is the difference between climbing a wall and being given the house key.
And the role attached to an instance running an agent tends to be generous, because nobody knew in advance which tools the agent would need to call.
Breaking the chain
You do not need to break all four links. One is enough, and several controls cost almost nothing:
- Require IMDSv2 and forbid IMDSv1. Version 2 uses a token obtained via PUT with a dedicated header, which defeats naive GET-based SSRF. On AWS, set
HttpTokens=required. On GCP, theMetadata-Flavor: Googleheader plays a similar role — but only if the tool cannot control request headers. - Set
HttpPutResponseHopLimit=1so the response does not traverse container layers. - Block 169.254.169.254 on egress from any process that accepts untrusted input. An nftables rule or a network policy handles it.
- Validate the destination before fetching: resolve DNS, reject private and link-local ranges, and re-check after redirects — otherwise a 302 undoes your validation.
- Remove the long-lived credential with workload identity federation. If there is no static key on the instance, the prize shrinks.
The ten-minute test
List the tools your MCP servers expose and mark the ones taking a URL, file path or hostname as an argument. For each, ask whether that process can reach 169.254.169.254. If it can, the whole chain is already assembled, waiting for someone to walk it.
