How to check an MCP server for SSRF yourself
If a tool takes a URL and the server fetches it, assume SSRF until you have watched it refuse a request to a private address.
Test a server you are considering, yourself, before you install it anywhere that matters.
How to check an MCP server for SSRF yourself works, in one picture
The same argument as the text, as a chain. Each step is what makes the next one possible.
- 1
Find every tool that accepts a URL
Read the server's own tool list. Anything with a parameter named url, uri, endpoint, webhook, src, image or callback is in scope, and so is anything taking a document or page identifier that the server resolves for you.
This is a larger set than people expect. A tool that summarises a web page is obvious. A tool that renders a preview, imports a spreadsheet or checks a link is the same shape wearing different words.
Tools that accept a file path count too, if the server will follow a path that turns out to be a URL.
- 2
Point it at your own machine, and watch
Locally, before the server touches anything realRun the server locally with a listener on a port nothing else is using, then call the tool with a URL pointing at that port. If your listener receives a request, the server fetches whatever it is given.
That alone is not a finding. It becomes one at the next step, which is whether it will fetch somewhere it should never be able to reach.
- 3
Try the four addresses that matter
The cloud metadata address, the loopback address, a private range address on your own network, and a redirect: a public URL you control that responds with a redirect to one of the first three.
The redirect is the one that catches otherwise careful software. A server can validate the URL it was handed, fetch it, and follow the redirect without validating again, which means the check it passed never applied to the request it actually made.
Test the redirect case even when the first three are refused. Refusing the obvious addresses and following a redirect to them is a common and complete failure.
- 4
Read what comes back, not just whether it connected
A blocked request should fail clearly and say so. A request that connects and returns an error page has still reached a host on your internal network, and an attacker learns from the difference between one error and another.
Time the responses as well. A server that refuses instantly for a blocked host and hangs for a real one has just told an attacker which internal addresses exist.
- 5
Then check whether it declares an egress list at all
The verification panel on every listing, under network egressA server that publishes the hosts it may contact has made a commitment you can hold it to and a control you can enforce. One that does not has, in effect, declared every host, and every other permission you grant it becomes a data-loss permission.
In a large independent scan of public MCP servers in 2026, more than a third of URL-accepting servers failed exactly this check, which is why it is one of the sixteen in our rubric rather than an optional extra.
You have watched a server either refuse or follow a redirect to a private address, and you know which.
Read next
If a tool takes a URL and the server fetches it, assume SSRF until you have watched it refuse a request to a private address.
Every one shows its exact method, and the circumstances in which it is wrong. Free, and no account to look.