Microsoft MarkItDown MCP: Pass It a URL, Get Back AWS Keys
BlueRock Security disclosed a server-side request forgery (SSRF) vulnerability in Microsoft's MarkItDown MCP server on January 20, 2026. The server's convert_to_markdown tool accepts an arbitrary URI with no validation, URL allowlist, or private IP restriction. When deployed on an AWS EC2 instance with IMDSv1 enabled, any user or agent calling the tool can reach the instance metadata service at 169.254.169.254, retrieve IAM role credentials including access keys, secret keys, and session tokens, and use them to authenticate against the AWS API with whatever permissions that instance role carries. Microsoft classified the finding as low-risk. As of disclosure, no patch has been provided. BlueRock's broader scan of 7,000 MCP servers found the same SSRF exposure pattern in approximately 36.7% of them.
What happened
Microsoft's MarkItDown is a popular document-conversion library with over 85,000 GitHub stars. Its MCP server exposes a single tool, convert_to_markdown, that accepts a URI pointing to a file or remote resource and converts it to Markdown for LLM consumption. The tool fetches whatever URI it receives from its server-side network context.
David Onwukwe at BlueRock Security identified the missing constraint. The tool applies no validation to the URI, no private IP filtering, no URL allowlist, and no restriction on metadata service addresses. On an AWS EC2 instance running IMDSv1, the sequence is mechanical: call convert_to_markdown with http://169.254.169.254/latest/meta-data/iam/security-credentials/ to get the instance role name; append the role name to the same base URL to retrieve access keys, secret keys, and session tokens. Those credentials authenticate directly against the AWS CLI and API with whatever IAM permissions the instance role holds. Depending on the role, the path from SSRF to full account administrator access is direct.
The attack surface extends beyond direct use. Any agent using the MarkItDown MCP server can be instructed by a prompt injection to fetch the metadata endpoint. The tool does not distinguish legitimate document conversion from metadata exfiltration at the protocol level.
Microsoft's assessment: low risk. Their rationale is that the server is recommended for local stdio use, not network deployment. BlueRock's scan of 7,000 MCP servers found that roughly 36.7% carry the same class of SSRF exposure, suggesting the unsafe default is common across the ecosystem regardless of vendor intent.
The PolicyLayer angle
Microsoft's response illustrates a recurring pattern: the vendor calls a vulnerability low-risk based on intended deployment, while the actual deployment reality is quite different. The recommendation to run on stdio locally is sensible advice. It is not a security control. Any organisation that deployed MarkItDown MCP on a cloud instance, or that runs it behind an HTTP transport for team access, is exposed regardless of the vendor's recommended configuration.
The controls that neutralise this attack independently of whether Microsoft ships a patch: deny outbound requests from the MCP server to link-local address ranges (169.254.0.0/16) at the network layer and at the application layer via tool input validation. Allowlist acceptable URI schemes and hostnames at the agent policy layer, so that any tool call containing an unrecognised URI pattern is flagged for review before execution. Enforce IMDSv2 on all EC2 instances, which requires a session token that SSRF cannot easily obtain. None of these wait for a vendor patch.
The 36.7% figure from BlueRock's scan matters because it shows the MarkItDown finding is not a one-off. Any MCP server that accepts a URI or URL parameter and fetches it from the server context is a potential SSRF vector. The policy layer's URI allowlist, applied uniformly to all tool inputs matching URI patterns, is the only control that covers the class rather than the specific instance.
Mitigations
Microsoft has not issued a patch and classifies the finding as low risk for the recommended local stdio deployment. If you run the MarkItDown MCP server, do not expose it over the network, and enforce IMDSv2 on any cloud instance so metadata credentials cannot be retrieved by simple GET-based SSRF. Restrict the convert_to_markdown tool’s egress with an allowlist that blocks link-local and private IP ranges, including 169.254.169.254. Run the server under an instance role scoped to least privilege, and treat any agent instruction to convert a URL as untrusted input.
FAQs
No. The attack demonstrated by BlueRock targeted EC2 IMDSv1. The same technique applies to any cloud provider using a link-local metadata endpoint, including GCP's 169.254.169.254 and Azure's equivalent. IMDSv2 mitigates the attack by requiring a session token that cannot be obtained via simple GET-based SSRF.
Because Microsoft's low-risk classification is based on intended use, local stdio deployment. Real-world deployments routinely run MCP servers over HTTP for team access, and BlueRock's scan found that 36.7% of 7,000 MCP servers carry the same SSRF pattern. The vendor's recommendation is not a control.
Yes. Any content an agent reads, a webpage, a document, a tool response, that instructs the agent to convert a URL via the MarkItDown tool can trigger the SSRF. The agent cannot distinguish a legitimate document URL from a metadata endpoint at the semantic level.