One in three MCP servers is an SSRF gateway to your cloud metadata

What is this?

The Model Context Protocol (MCP) is the connective tissue between AI agents and the outside world: file systems, databases, APIs, and cloud services. Two independent 2026 measurement efforts now suggest that a large slice of the public MCP ecosystem ships the same web vulnerability class that has plagued backend software for a decade — server-side request forgery (SSRF).

Trend AI Security scanned 9,695 MCP servers across GitHub, Glama, Lobehub and PulseMCP; the results were reported on July 7, 2026. It found 5,832 servers with security issues and 2,259 confirmed exploitable beyond simple missing-auth gaps, cataloguing 4,982 distinct issues including 422 SSRF flaws, 880 arbitrary file-access flaws, 476 command-injection flaws and 185 prompt-injection cases. Separately, BlueRock’s January 2026 analysis of more than 7,000 servers in its MCP Trust Registry reported that over 36.7% carried a potential SSRF (“unrestricted network fetch”) finding. Different corpora, same message: SSRF is not an edge case in MCP land, it is the baseline.

How it works

An MCP server is more than a request handler. When an agent calls one of its tools, the server acts: it fetches URLs, reads files, runs code. SSRF appears whenever a tool accepts a URL or host argument and then fetches it without validation.

BlueRock’s worked example is Microsoft’s MarkItDown MCP server — a document-to-Markdown converter with roughly 85k GitHub stars. Its convert_to_markdown tool accepts an arbitrary URI and fetches it with no scheme or host restriction. On an AWS EC2 instance still using the legacy IMDSv1 metadata service, an agent (or an attacker who can steer the agent) can point that tool at the cloud metadata endpoint:

convert_to_markdown("http://169.254.169.254/latest/meta-data/iam/security-credentials/")
# → returns the attached IAM role name
# append the role name to that path → access key, secret key, session token

Those returned credentials can then be replayed against the cloud API, giving account access scoped to the instance role — and, depending on that role, a path to privilege escalation across the account. The critical point is architectural: this exposure lives at the tool-execution layer, below the request boundary that MCP gateways inspect. A gateway can wave a valid-looking request through and still let the server exfiltrate credentials during execution.

Why it matters

The more uncomfortable finding is about trust signals. The Trend AI Security scan reports no meaningful correlation between a server’s popularity and its security: high-popularity servers (50+ stars) often carry the greatest risk because their blast radius is larger, commit activity did not predict safety, and directory “verified” badges barely moved the needle — verified servers had nearly the same average vulnerability count as unverified ones. The heuristics teams instinctively reach for when picking a dependency — stars, activity, a verification checkmark — are close to worthless as security indicators here.

Because MCP servers frequently run with the privileges of the user or workload that launched them, an SSRF or file-access flaw is rarely contained to the tool. It is a pivot into whatever that identity can reach: cloud metadata, internal services, secrets. When the same popular server is deployed across many organisations, one flaw becomes systemic — what BlueRock and the scan authors both frame as severity weighted by reach.

Defenses

Treat every third-party MCP server as untrusted code running inside your trust boundary, and constrain what its tools can fetch:

• Allowlist egress. Restrict tool fetches to an explicit scheme/host allowlist (for example, only https:// to approved domains) rather than blocklisting.
• Block internal targets. Deny RFC1918 ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback, link-local, and the cloud metadata IP 169.254.169.254.
• Defeat DNS rebinding. Resolve the hostname and check the resolved IP against the denylist before connecting, not just the string.
• Kill IMDSv1. Enforce IMDSv2 (session-token required) on every instance; it exists specifically to blunt SSRF-to-metadata theft. Pair it with least-privilege instance roles.
• Prefer stdio, local. Run MCP servers over stdio bound to localhost rather than exposing them over HTTP; set request timeouts, body-size caps, and strip forwarded Authorization/Cookie headers.
• Watch execution, not just requests. Monitor what tools actually do at runtime; gateway-only inspection misses the layer where this class of bug fires.
• Drop the trust heuristics. Do not treat stars, commit velocity or a verification badge as a security signal. Audit the code or scan the server before you connect it.

Status

Item	Detail
MarkItDown MCP SSRF	Reported to Microsoft and AWS in November 2025; both responded that workarounds are available. Public disclosure January 2026. No CVE assigned.
Ecosystem SSRF prevalence	BlueRock: >36.7% of 7,000+ servers (Jan 2026). Trend AI Security: 422 SSRF among 4,982 issues across 9,695 servers (Jul 7, 2026).
Mitigation	IMDSv2, egress allowlisting, and execution-layer monitoring available today; adoption is the gap.

Sources: Trend AI Security’s “Stars Don’t Save You” MCP ecosystem study (reported July 7, 2026), and BlueRock’s “MCP fURI” disclosure on the Microsoft MarkItDown server (January 2026).