MCP fURI: BlueRock Discovers an MCP Security Gap That Enables Account Takeover of Cloud Infrastructure

Summary

Model Context Protocol (MCP) is an open standard developed by Anthropic that provides a unified way for AI applications and agents to connect with external data sources and tools. Its adoption as a standard to expose common methods to access data has grown rapidly and thousands of MCP servers have been published over the past year. 

While powerful, MCP servers left unchecked can also create security holes that allow attackers to take advantage of this interface layer for purposes of privilege escalation, lateral movement and data exfiltration.  

We have discovered a vulnerability in Microsoft's Markitdown MCP server when running in an AWS cloud environment on an EC2 instance. This vulnerability allows an attacker to execute the Markitdown MCP tool convert_to_markdown to call an arbitrary uniform resource identifier (URI).  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 research for this vulnerability was started by using BlueRock’s MCP Trust Registry (https://mcp-trust.com) which provides a comprehensive security analysis of over 7,000 MCP servers across a set of security rules and MCP tool analysis.  By filtering findings on servers with a Server Side Request Forgery (SSRF) unrestricted network fetch security finding and selecting a server with high adoption – in this case, Microsoft’s Markitdown MCP server has 85k stars on GitHub – an instance of the server was deployed and evaluated for potential security gaps. 

MCP Trust Registry Profile

Microsoft Markitdown MCP Server — Security Analysis

Screenshot: MCP Trust Registry security profile for Microsoft Markitdown, showing SSRF vulnerability flag

In the case of AWS, this vulnerability affects EC2 instances that are using IDMSv1, with the potential to affect any cloud provider using IDMSv1 for their instances. When providing a URI to the Markitdown MCP server, this can be used to query the instance metadata of the server. A user can then obtain credentials to the instance if there is a role associated, giving you access to the AWS account including the access and secret keys. Depending on the level of access the EC2 role has, this could lead to full admin access of the AWS account. If the user has configured this MCP server on HTTP, the metadata can be queried from a remote server. 

This class of vulnerability could be potentially leveraged by ANY MCP server running on EC2 that accepts an argument that allows for querying the IMDSv1 service. Based on our analysis of over 7,000 MCP servers, over 36.7% have potential exposed SSRF vulnerabilities. Furthermore, a compromised endpoint running the MCP server locally would allow for privilege escalation and SSRF attacks with the full rights of the user running such server.

The Systemic Problem

This class of vulnerability could be potentially leveraged by ANY MCP server running on EC2 that accepts an argument that allows for querying the IMDSv1 service. Based on our analysis of over 7,000 MCP servers, over 36.7% have potential exposed SSRF vulnerabilities.

Furthermore, a compromised endpoint running the MCP server locally would allow for privilege escalation and SSRF attacks with the full rights of the user running such server.

Why is this happening?

1. MCP is new and rapidly growing. With the rapid adoption of MCP servers, security best practices haven’t caught up with adoption.

2. Red teaming and code reviews are lacking. Threat modeling, adversarial scenarios and implementing constraints are optional.

3. Trust assumptions. Server builders may assume the agent (or user) will only execute expected behavior.

But agents are non-deterministic. Users make mistakes. And attackers exploit assumptions.

NOTE: This vulnerability was reported to Microsoft and AWS who both responded that workarounds are present to mitigate this issue.

Technical Details

1. What is IMDSv1? 

IMDSv1 is the older version of the Amazon EC2 Instance Metadata Service that allows instances to access metadata, such as information around the EC2 instance or even credentials. Amazon recommends that customers use IMDSv2 which requires a session token before you can make API calls. This helps to protect against SSRF attacks.

2. What is Microsoft MarkItDown MCP? 

Microsoft has created a python tool called MarkItDown that can convert various files, such as pdfs, html, word, and more, to the markdown language. Microsoft has created an MCP server for MarkItDown (https://github.com/microsoft/markitdown/tree/main/packages/markitdown-mcp) that can work with various LLMs to convert these files to Markdown. You can create the MCP server using Microsoft’s documentation and run the server on stdio, sse, or http. Note: Microsoft recommends running this on stdio(locally) for security reasons.

3. How does using MarkItDown MCP lead to an SSRF attack on IDMSv1?

MarkItDownMCP does not validate the urls provided to it. If you provide the instance metadata IP (http://169.254.169.254), the MCP client will provide that data back to you. For instance, I can append /latest/meta-data/iam/security-credentials to the metadata IP to get the instance role. Once I have the instance role name, I can append that to the previous string and I will get an access key, secret key, and session token. I can then leverage those credentials to access the AWS account via CLI. Depending on the IAM role the EC2 instance has, I could potentially access sensitive data/resources in that AWS account. Depending on the permissions, I could even elevate my own permissions. 

Remediation

How can developers address this security gap? Unconstrained HTTP clients enable SSRF attacks. Developers should consider implementing private IP blocking, restricting access to metadata services, and supporting an allowlist to prevent data exfiltration. Check your servers. Use MCP Trust Registry to see what risks exist before you connect.

Additional measures that can be taken are as follows:

• Implement strict URI scheme/host allowlist (e.g., only https:// to approved domains)

• Blocking unnecessary RFC1918 private IPs (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), loopback, link-local, and cloud metadata IPs

• Add DNS rebinding protections by resolving hostname and checking IP before connection

• Set timeout and max body size limits on HTTP requests

• Strip or validate forwarded headers (Authorization, Cookie) to prevent credential leakage

The Bigger Picture

MCP is becoming the standard for how AI agents connect to tools. That’s a good thing: interoperability, shared standards, faster development.

But it also means the attack surface is shifting.

Traditional security focuses on prompts, what you ask the agent to do. The real risk is in actions—what the agent actually does when it runs.

An MCP server doesn’t just take requests. It fetches URLs, reads files, executes code, and accesses data. If you’re only watching the request layer, you’re missing where the risk actually lives.

This is the iceberg problem. Gateways see tool requests—the tip. But the real exposure is below the waterline: the runtime layer where agents access internal resources, exfiltrate data, and escalate privileges.

That’s where this vulnerability lives. And that’s where the next hundred vulnerabilities will live too.

How BlueRock Addresses This

We built BlueRock because we saw this coming. BlueRock MCP Protection mechanisms can protect your environment against these types of attacks. 

First, using BlueRock you can actually block the metadata URI from being accessed in the system. The IP 169.254.169.254 is the universal metadata IP for most cloud service providers. BlueRock can mitigate this by blocking the IP from being accessed in any scenario, not just this specific example. 

Second, BlueRock can prevent the MCP server from being deployed as an http server. We can enforce the transport layer protocol that MCP uses so that only stdio is allowed. This means that even if someone tried to run the Markitdown MCP as an http server, it would not establish connections via http. 

Microsoft’s guidance on their Github repo says: “The server does not support authentication, and runs with the privileges of the user running it. For this reason, when running in SSE or Streamable HTTP mode, it is recommended to run the server bound to localhost (default).”. 

However, this could still be exploited at the stdio level, which is why we recommend the URI blocking as listed above.

Lastly, BlueRock has built in SSRF protection. This will help mitigate against various SSRF attacks against your MCP environment. BlueRock also has protections for path traversal and deserialization attacks. 

MCP server builders. You can request a scan of your server in a public GitHub repo here. If you need help or have questions, please contact us via email: customer-support@bluerock.io, or at Discord server or on Reddit.

Disclosure Timeline

About BlueRock & Resources

BlueRock is the Agentic Protection Platform—visibility and security for AI agents and MCP servers across tools, data, and code execution. We've scanned over 7,500 MCP servers and counting.

• Check your MCP servers: mcp-trust.com

• See BlueRock in action: Request a demo

David Onwukwe is Principal Solutions Engineer at BlueRock, where he focuses on agentic security research and customer solutions.