This SSRF in an MCP server's fetch tool is being scored at CVSS 6.3. That score is wrong, and here's why: the actual blast radius isn't determined by the vulnerability in isolation — it's determined by what the AI agent can reach. In traditional SSRF, an attacker makes requests directly. In MCP infrastructure, the attacker crafts a malicious prompt, the LLM invokes the fetch tool legitimately, and the request inherits whatever permissions the agent holds. If that agent has access to AWS metadata, cloud consoles, or internal services, the exploit chains into all of them. The CVSS number captures the vulnerability; it captures nothing about the trust relationship between the user, the LLM, and the infrastructure the agent can touch. That's the real score, and it's unbounded by design.
The exploit is publicly available, meaning prompt injection toolkits can weaponize this directly. But the more important signal is the maintainer's non-response to early notification. In the MCP ecosystem, servers are often scaffolding — written to connect one tool to one LLM, then abandoned when the developer moves on. The code persists in whatever deployment inherited it. This isn't a 'workflow failure' in the sense of a process that can be fixed with better code review. It's the natural endpoint of infrastructure treated as disposable. The vulnerability exists, the patch may never arrive, and the exposure window grows as the agent gains new integrations.
What to do: validate every URL passed to fetch — scheme allowlists (http/https only), block internal IP ranges, and consider scoping fetch to environment-specific endpoints rather than arbitrary URLs. The MCP specification provides no built-in guardrails for tool parameter validation; every server is independently responsible for this calculation. If you're deploying an MCP server, assume it can be invoked via prompt injection and design accordingly.