The Model Context Protocol security conversation has a glamour problem. Almost everything written about it concerns attacks that feel native to the age of agents: prompt injection, tool poisoning, and rug pulls — clever manipulations of a model that reads instructions it shouldn't. They make for good conference talks because they are genuinely new. The model is the mark, and watching a language model get socially engineered is novel theater.
Then someone counted. When the security firm BlueRock scanned more than 7,000 MCP servers, the single most prevalent serious flaw was not any of those. It was server-side request forgery — present in 36.7% of them. SSRF is the opposite of glamorous. It is a web vulnerability so old and so well-documented it has its own OWASP cheat sheet and a famous body count: the 2019 Capital One breach, 100 million records, was one SSRF request away.
The exploit is "summarize this page"#
BlueRock's proof of concept didn't pick an obscure target. It used Microsoft's own MarkItDown MCP server — a popular tool whose entire job is to take a URL or a file and convert it to markdown. They named the finding "MCP fURI," for the unrestricted URI it will happily fetch.
The mechanism is embarrassingly simple. The convert_to_markdown tool accepts any URI and fetches it with no validation. Run that server on an AWS EC2 instance and hand the tool http://169.254.169.254 — the cloud metadata endpoint, a link-local address every cloud instance can reach itself on — and it returns the instance's metadata. Append the IAM role name it just disclosed, and the next fetch returns that role's temporary credentials: an access key, a secret key, and a session token. From there an attacker has whatever the role can touch — S3, DynamoDB, and, if the role is over-provisioned, the account.
Here is the part the prompt-injection framing misses entirely.
The model never has to be jailbroken. "Convert this URL" is the attack — and that is a request the agent is supposed to honor.
There is no adversarial suffix, no hidden instruction, no poisoned tool description. A user pastes a link. A document the agent was asked to process contains one. The agent does exactly what it was built to do, and the server fetches exactly what it was told to. The intelligence in the loop is irrelevant; you could replace the model with a for loop and the credentials still walk out the door.
The agent didn't invent the bug — it mass-produced it#
This is the uncomfortable insight. An MCP server that takes a URL and fetches it is, by construction, an SSRF sink. That's not a flaw in a particular implementation — it's the definition of the category. What MCP changed is distribution. We took a vulnerability class that used to live in a handful of carefully reviewed web backends and packaged it into thousands of one-click servers, then installed them on developer laptops and CI runners that hold long-lived cloud credentials.
It is not just MarkItDown. The same fetch-an-arbitrary-URL pattern produced CVE-2026-39974 in the n8n-MCP server and the unauthenticated SSRF-to-RCE chain Pluto Security found in the Atlassian MCP server. When a vulnerability shows up across unrelated servers from unrelated vendors, it isn't a bug. It's the protocol's blind spot meeting an old habit.
And Microsoft's response to MarkItDown tells you how the ecosystem is treating it: they characterized the SSRF as low risk and declined to ship a patch — sanitization, in their framing, is the developer's job. That's the same posture vendors took on the STDIO transport finding earlier this year. It may even be technically defensible. It is also how an entire category of preventable breaches gets normalized.
The fix is 2019 hygiene, not AI safety#
The relief, if there is one, is that you don't need a research breakthrough to close this. SSRF defense is a solved problem that the agent rush simply skipped:
- Validate the URL after DNS resolution, not before — a friendly hostname can resolve to
169.254.169.254. Reject anything landing on loopback, RFC1918, or link-local (169.254.0.0/16), and prefer an allowlist to a denylist. Re-validate after every redirect, or disable redirects. - Block the metadata endpoint at the network layer. The server almost never needs to reach
169.254.169.254; deny it. - Enforce IMDSv2. Its required PUT-token handshake defeats the naive GET that SSRF depends on. The MarkItDown exploit works against IMDSv1; on IMDSv2 the same request comes back empty.
- Run the server least-privilege, ideally behind an MCP gateway that can enforce egress policy in one place instead of trusting each tool.
None of that is exotic. All of it predates the word "agent." The lesson isn't that MCP is uniquely dangerous — it's that wrapping an old capability in a new abstraction doesn't retire the old capability's vulnerabilities; it ships them to people who've never heard of them. Prompt injection earns the keynote. SSRF, quietly, gets your AWS account — and it's already living in more than a third of the servers you might install this week.



