Nik Kale
Nik Kale
Building Intelligent Systems That Operate Themselves Securely
⌘K
Subscribe Sign in
Nik Kale
Enterprise Security

36.7% of MCP Servers May Be Vulnerable to SSRF - The Supply Chain Crisis Nobody's Talking About

Analysis suggests over a third of MCP servers may be vulnerable to server-side request forgery. The MCP ecosystem has a supply chain problem: rapid adoption without security review created a vulnerability surface that scales with every new deployment.
36.7% of MCP Servers May Be Vulnerable to SSRF - The Supply Chain Crisis Nobody's Talking About

The Model Context Protocol’s value proposition rests on standardization. Instead of building custom integrations for every data source and tool, enterprises use MCP servers as a universal connector layer between AI agents and the systems they need to access. By late 2025, the ecosystem had grown to over 13,000 published MCP servers on GitHub, covering everything from developer tools to enterprise database connectors. The standardization was working. The security wasn’t.

BlueRock Security’s research, published in late 2025 and covered extensively in January 2026, provided the first systematic analysis of MCP server security across the ecosystem. The results were worse than most security professionals expected. The vulnerability pattern they identified-SSRF through unrestricted network fetch operations-wasn’t a novel attack technique. SSRF has been on the OWASP Top 10 since 2021. What made the finding significant was its prevalence: more than one in three MCP servers shared the same fundamental flaw.

The MarkItDown proof of concept

BlueRock’s researchers started with Microsoft’s MarkItDown MCP server, one of the most widely deployed MCP servers in the ecosystem. MarkItDown does something deceptively simple: it converts files from various formats (PDFs, HTML, Word documents) into Markdown that LLMs can process. Users provide a URI, and MarkItDown fetches whatever is at that URI and converts it.

The problem: MarkItDown doesn’t restrict what URIs it will fetch. As David Onwukwe, BlueRock’s principal solutions engineer, explained in the disclosure: “This vulnerability allows an attacker to execute the MarkItDown MCP tool convert_to_markdown to call an arbitrary uniform resource identifier. The lack of any boundaries on the URI allows any user, agent, or attacker calling the tool to access any HTTP or file resource.”

The implications are severe, particularly in cloud environments. When MarkItDown runs on an AWS EC2 instance-a common deployment pattern-an attacker can point it at the instance metadata service at 169.254.169.254. The metadata service is AWS’s mechanism for providing configuration information to running instances, and crucially, it contains temporary security credentials for any IAM role attached to the instance.

By sending a request like convert_to_markdown("http://169.254.169.254/latest/meta-data/iam/security-credentials/"), an attacker retrieves the access key, secret key, and session token for the EC2 instance’s IAM role. Depending on the permissions attached to that role, this could mean read access to S3 buckets, write access to databases, or full administrative control over the AWS account.

Harold Byun, BlueRock’s chief product officer, told Dark Reading: “It could be a file that is internal; it could be any other file that is accessible via the network, to that given server, any other type of arbitrary call that you would want to make.” The vulnerability class isn’t limited to cloud metadata. An attacker can reach internal APIs, configuration endpoints, databases, and any other network resource accessible from the server’s network position.

The 36.7% problem

The MarkItDown vulnerability would be concerning on its own-85,000 GitHub stars means significant deployment. But BlueRock’s broader analysis revealed that the vulnerability pattern wasn’t unique to Microsoft’s server.

Using their MCP Trust Registry, BlueRock scanned more than 7,000 MCP servers across 22 security rules aligned with the OWASP MCP Top 10 and MITRE CWE frameworks. The finding: 36.7% of MCP servers had potential SSRF vulnerabilities similar to the MarkItDown flaw. The servers accept URIs, file paths, or network addresses as input parameters and fetch the specified resources without validating that the target is a permitted destination.

The prevalence makes sense when you understand how MCP servers are built. MCP’s design pattern involves tools that connect AI agents to external data sources. Many of those tools need to fetch data from URLs, read files, or query APIs. The standard implementation pattern-accept a URI parameter, fetch the resource, return the content-is also the standard SSRF pattern. The vulnerability isn’t a coding mistake; it’s an architectural choice that most MCP server developers make without considering the security implications.

Adversa AI’s February 2026 roundup of MCP security research placed SSRF as one of the most prevalent vulnerability classes across the MCP ecosystem, alongside command injection and path traversal. The report characterized the situation as demonstrating that “security practices are inconsistent even in popular MCP tool repositories” and urged enterprises to “treat every tool execution as a potential vector for indirect injection.”

The supply chain dimension

The SSRF prevalence in MCP servers creates a supply chain security problem that most enterprises haven’t fully grasped.

When an organization deploys an MCP server, they’re not just deploying a connector. They’re deploying a network proxy that their AI agents will use to access external and internal resources. If that proxy doesn’t restrict where it can reach, every AI agent connected to it inherits the ability to access arbitrary network resources-internal APIs, cloud metadata, adjacent services, anything reachable from the server’s network position.

The supply chain risk compounds because MCP servers are typically sourced from open-source repositories. An enterprise’s security review process for open-source dependencies may not include the kind of network security analysis that SSRF detection requires. Standard vulnerability scanning tools look for known CVEs and code-level bugs. The SSRF pattern in MCP servers isn’t a bug-it’s a feature (unrestricted resource fetching) that becomes a vulnerability when deployed in a network with sensitive internal resources.

Composio’s analysis of MCP vulnerabilities documented several real-world incidents that illustrate the supply chain dimension. In June 2025, Supabase’s Cursor agent-running with service_role access-processed support tickets containing user input as commands. An attacker embedded SQL instructions in a support ticket, and the agent executed them, exposing authentication tokens in a public support thread. The same month, Asana pulled its MCP integration offline for two weeks after discovering that customer information was bleeding between MCP instances.

These incidents share a common pattern: MCP servers were deployed with the assumption that all inputs would be trustworthy, and that assumption was exploited through the normal operation of the system-not through a sophisticated attack, but through an unrestricted input parameter that became an open door.

Why traditional SSRF defenses aren’t enough

Enterprise security teams that have dealt with SSRF before might think the defense playbook is straightforward: implement URL allowlists, block access to metadata endpoints, restrict internal network access from externally-reachable services. These are correct defenses. But MCP’s architecture adds complications that traditional SSRF mitigation doesn’t address.

First, MCP servers are often intended to fetch arbitrary resources. A file conversion tool, a web scraping tool, a document retrieval tool-these tools are designed to access diverse URIs. Implementing a strict allowlist for a tool whose purpose is to fetch anything the user points it at is functionally equivalent to disabling the tool. The defense can’t be “don’t let it fetch arbitrary URIs” when fetching arbitrary URIs is the use case.

Second, MCP servers operate as intermediaries for AI agents, not for human users. An AI agent deciding which URI to send to an MCP server is making that decision based on its reasoning process, which may be influenced by prompt injection, tool poisoning, or the session smuggling attacks documented by Unit 42. The URI isn’t necessarily one the user intended to fetch-it might be one that a malicious input caused the agent to generate.

Third, the proliferation of MCP servers means organizations may have dozens or hundreds of MCP connections, each with different security postures. Managing SSRF defenses across a fleet of MCP servers from different sources, maintained by different teams, and connecting to different resources is an operational challenge that most security teams haven’t staffed for.

What this means for enterprise MCP adoption

My experience building AI-powered platforms has taught me that standardization is valuable precisely because it creates consistent patterns-and those patterns can be secured systematically if the security architecture is designed alongside the integration architecture. MCP’s SSRF problem isn’t a reason to abandon the protocol. It’s a reason to treat MCP server deployment as a security-critical operation that requires the same rigor as deploying any other network service with access to sensitive resources.

The 36.7% figure from BlueRock should be understood not as “one-third of MCP servers are insecure” but as “one-third of MCP servers follow a design pattern that creates SSRF risk, and that design pattern is the default.” Fixing this requires changing the default, which means applying security controls at the infrastructure layer rather than relying on individual MCP server developers to implement restrictions.

What to do Monday morning

Audit every MCP server connection for SSRF exposure. Inventory all MCP servers in your environment. For each one, determine whether it accepts URI, URL, file path, or network address parameters. If it does, test whether it will fetch internal network resources, cloud metadata endpoints (169.254.169.254), or localhost services. This is your SSRF exposure surface.

Implement network segmentation for MCP servers. MCP servers should run in network segments that restrict what internal resources they can reach. Block access to cloud metadata endpoints from MCP server processes. Use security groups or firewall rules to limit MCP servers to only the external resources they legitimately need to access.

Deploy URL validation and allowlisting. For MCP servers that need to fetch external resources, implement server-side URL validation that blocks requests to private IP ranges (10.x.x.x, 172.16-31.x.x, 192.168.x.x), link-local addresses (169.254.x.x), and localhost. Maintain allowlists of permitted external domains where feasible.

Migrate to IMDSv2 for cloud instances. If you run MCP servers on AWS EC2 instances, ensure you’re using Instance Metadata Service Version 2 (IMDSv2), which requires session tokens and is resistant to SSRF-based metadata theft. IMDSv1 is vulnerable by design. “The reality is the vast majority of instances in Amazon are on Instance Metadata Service v1,” Byun noted-which means most cloud-deployed MCP servers are exposed.

Establish a security review process for new MCP servers. Before any MCP server is connected to your agent infrastructure, it should undergo a security review that specifically evaluates SSRF risk, command injection risk, and path traversal risk. BlueRock’s MCP Trust Registry provides community-sourced risk ratings for over 8,000 servers-use it as a starting point, not a substitute for your own assessment.

The ecosystem maturity problem

The MCP SSRF problem is, at its core, an ecosystem maturity problem. MCP servers are being built, published, and deployed at a pace that far outstrips the security review capacity of the community. Twenty-two thousand new MCP repositories were created in a single recent month-thirty every hour. The vast majority of those servers are built by developers focused on functionality, not security.

This isn’t a criticism of MCP server developers. It’s a recognition that ecosystems built on open-source contributions require security infrastructure that individual contributors shouldn’t be expected to provide. The MCP ecosystem needs systematic security analysis, community-maintained security benchmarks, and deployment tooling that enforces security baselines by default.

Until that infrastructure matures, enterprise security teams are the last line of defense. Treat every MCP server as a network service with access to sensitive resources, because that’s exactly what it is. The 36.7% figure is the floor, not the ceiling-the actual exposure in any given enterprise environment depends on how many of those servers are connected to internal networks, cloud accounts, and production data.

More like this

An AI Agent Just Pwned Trivy, Microsoft, and DataDog in One Week

An AI Agent Just Pwned Trivy, Microsoft, and DataDog in One Week

An autonomous AI agent scanned 47,000+ repositories, identified vulnerable CI/CD configurations, and compromised projects from Microsoft, DataDog, and Aqua Security using five distinct techniques. The only target that survived was defended by another AI agent.
88% of You Have Already Had an AI Agent Security Incident. The Other 12% Probably Don’t Know Yet.

88% of You Have Already Had an AI Agent Security Incident. The Other 12% Probably Don’t Know Yet.

Gravitee surveyed 900+ executives and found 88% reported AI agent security incidents, while 82% believed their policies were adequate. The gap between executive confidence and operational reality is the most dangerous metric in enterprise AI security right now.
The npm Nightmare Just Repeated Itself in AI Agents. It’s Worse This Time.

The npm Nightmare Just Repeated Itself in AI Agents. It’s Worse This Time.

1,184 malicious skills infiltrated ClawHub, the plugin marketplace for the OpenClaw agent framework, reaching 20% of the ecosystem in weeks. Unlike npm packages, agent plugins run with full system permissions. The supply chain playbook broke because the blast radius changed.
AI Security Fundamentals: An Architectural Playbook

AI Security Fundamentals: An Architectural Playbook

An architectural foundation for AI security covering the mechanisms that matter, emerging protocols, and the failure modes that appear when teams focus on the model while ignoring the system.
Palo Alto’s Unit 42 Just Found a Way to Hijack AI Agent Conversations - And Your Users Can’t See It Happening

Palo Alto’s Unit 42 Just Found a Way to Hijack AI Agent Conversations - And Your Users Can’t See It Happening

In November 2025, Palo Alto Networks’ Unit 42 research team published a new attack technique they called “Agent Session Smuggling.” The attack exploits a fundamental property of multi-agent systems: agents remember their recent conversations.
MCP Just Got a New Home at the Linux Foundation - But Its Security Debt Followed It There

MCP Just Got a New Home at the Linux Foundation - But Its Security Debt Followed It There

The protocol arrives at its new home carrying five critical CVEs from its first year, a 36.7% SSRF prevalence rate across its ecosystem, and an authentication architecture that the specification itself had to retroactively mandate.