Are MCP servers vulnerable to SSRF?

Many MCP servers expose tools that make network requests as their core function — fetching a webpage, calling a REST API, checking a status endpoint. The model decides the target URL or host based on the conversation, which means the server is effectively letting model-influenced input control where it sends outbound requests from its own network position.

If that server runs inside a cloud environment, it often has network access to infrastructure a public client never should — a cloud metadata service (commonly reachable at a fixed internal address on AWS, GCP, and Azure) that can hand back temporary credentials, an internal admin panel, or another service on the same private network. A request that looks like 'fetch this URL for the user' can instead be pointed at one of those, and the response — including any leaked credentials — gets returned as if it were normal tool output.

The obvious fix — block all outbound network access from the scanning/execution environment — directly conflicts with the fact that many MCP servers need real network access to function at all, and testing whether a server is live requires actually reaching its endpoint. A blanket 'no network access' policy quietly can't be true for a product that needs to probe live servers.

The workable middle ground is a default-deny network policy with one narrowly allowlisted, fully logged outbound proxy used only for that specific probe traffic — network access exists, but it's constrained and auditable rather than open.

The Safety dimension's scan for dangerous capability surface specifically includes network egress as a checked signal, and any live-endpoint probing aimcplist performs runs through an isolated, default-deny environment with a single logged, allowlisted proxy for probe traffic — not direct network access from the scanning infrastructure itself.