URL handling
Any tool accepting a URL refuses internal and metadata addresses, including after a redirect.
- Applies to
- MCP servers
- Standard references
- CWE-918
A finding here is not a failure
Software of any size carries something. A listing that raises findings on this check is still sold, with the findings published and their severity and reachability stated. A badge that only ever said pass would teach people to stop reading it.
Explainer · 2026-09-30
SSRF in MCP servers: when a tool that fetches a URL can be pointed at your own network
A tool that fetches whatever URL it is given will fetch internal addresses too, including the one cloud platforms use to hand out credentials. In an MCP server the URL is chosen by a model, which can be steered.
What this row checks
That any tool accepting a URL refuses internal and metadata addresses, including after a redirect. The check is on the tool's behaviour, not on the words in its description.
How it happens
Server-side request forgery is making a server send a request somewhere its operator never meant it to. The classic target is 169.254.169.254, the link-local address where cloud platforms serve instance metadata, often including credentials. Others are services on the private network or on the server's own loopback address that were never meant to be reachable from outside.
Naive defences fail in known ways. A check on the URL's text misses a public name that resolves to a private address, a redirect from a public page to an internal one, and DNS rebinding, where a name resolves one way when checked and another way when used.
Why MCP makes it worse
In an MCP server the URL argument is written by a model, and a model can be led to write one by text it read on a web page or in a document. Nobody has to type anything malicious. The MCP specification's own security guidance lists SSRF among the attacks on MCP clients, down to cloud metadata endpoints, DNS rebinding and redirect chains.
What a good defence looks like
Resolve the name, check every address it resolves to against the private and reserved ranges, and check again at the moment of connecting, not only before. Do not follow redirects, or check every hop. Where the set of destinations is known, allow only those.
One nuance from the hand run: a browser tool running on your own machine is meant to open internal addresses, because they are yours. The row matters most for a server that runs somewhere shared, where the internal network is somebody else's.
In the glossary: SSRF.
What this check has found
2 listings in the catalogue raise a finding here. Every one is still sold, with the finding printed on its page.
- Claude Flow Cli
Read by hand on 2026-09-30: Its browser tools navigate to any URL they are given, internal addresses included. On your own machine that is a browser tool's job; the row exists for servers that run somewhere shared.
- Zenlink MCP
Read by hand on 2026-09-30: zen_navigate and the tab tools open any URL, internal addresses included. A browser on your own machine is meant to; the row exists for servers that run somewhere shared.
Every listing in the catalogue shows its result on this check, with the findings summarised in public and the full report to whoever bought it. Open the catalogue.