Otto Support - SSRF and Token Passthrough with MCP

TL;DR: Server-side request forgery (SSRF) and token passthrough are old web vulnerabilities in new packaging. In an MCP server, a single mishandled URL can turn into RCE on a developer's laptop or a foothold inside a cloud account. This post walks three recent case studies for an mcp-atlassian CVE chain, Microsoft's MarkItDown SSRF, and the marketplace-plugin flaw in OpenClaw. As a closer, mitigations to defuse the risks documented in the case studies are discussed, including destination validation, network segmentation, and, for token passthrough, mostly just not doing it.

The previous blog in our otto-support CTF challenge series closed on the principle that an agent should hold only the tools its task requires. Two of the most common Model Context Protocol (MCP) capabilities also happen to be two of the most reliably dangerous. SSRF and token passthrough are not new concepts; SSRF has had its own entry in OWASP guidance for years, and token passthrough is the same confused-deputy problem OWASP has warned about under other names. What is new is how casually MCP server developers are reintroducing them while wiring up integrations to Atlassian, Microsoft, and the rest of the enterprise stack. This blog looks at the recent disclosures, including the chained SSRF-to-RCE in mcp-atlassian, and at the controls that prevent them.

What is SSRF & Token Passthrough in MCP?

Server-side request forgery (SSRF) via MCP follows a pattern similar to the classic web application attack. A tool accepts a URL parameter; the server makes the request, receives the content, and sends the response back to the caller. Without destination validation, the caller can point that server request at anything the server has network access to. This could include cloud metadata endpoints, internal admin panels, internal web services, segmented networks, or localhost services, to name a few.

Token passthrough occurs when an MCP server accepts tokens from a client without audience validation and passes them directly to a downstream API. This can result in security control circumvention, accountability and audit trail issues, trust boundary issues, and future compatibility risks.

MCP servers are particularly exposed to these issues because content retrieval tools are among their most common capabilities. Checking a URL or calling an API takes a user- or system-supplied URL to make a server-side request.

Case Studies

CVE-2026-27826: MCP-Atlassian SSRF to RCE

The most widely used MCP server for Atlassian integration, mcp-atlassian, had over 4 million downloads and 4,400 GitHub stars when researchers disclosed a critical vulnerability chain in February 2026. All versions prior to 0.17.0 were affected.

The SSRF (CVE-2026-27826, CVSS 8.2) lived in the HTTP middleware layer, not in any MCP tool handler. The server read custom headers X-Atlassian-Jira-Url and X-Atlassian-Confluence-Url to determine upstream API destinations without any URL validation. An unauthenticated attacker on the local network could inject a malicious URL in those headers and redirect the server's outbound requests to attacker-controlled infrastructure. The server also bound to 0.0.0.0 by default with no authentication, so anyone on the same network could reach the MCP server.

The researchers chained this with a separate path traversal vulnerability in the confluence_download_attachment tool (CVE-2026-27825, CVSS 9.1) to achieve a full attack sequence they called "MCPwnfluence." The SSRF exfiltrated sensitive files from a developer's machine, including AWS credentials, SSH keys, kubeconfig, and .env files. The path traversal then wrote executable code to ~/.bashrc or ~/Library/LaunchAgents/, achieving unauthenticated remote code execution on next shell invocation.

The fix in v0.17.0 added SSRF protections with domain allowlisting.

MarkItDown: Systemic SSRF Across 2,500 MCP Servers

In January 2026, researchers identified an SSRF vulnerability in Microsoft's MarkItDown MCP server, a tool that converts documents to Markdown format. The convert_to_markdown tool accepted arbitrary URIs with no input validation that would restrict access to internal or private IP ranges.

When running on an AWS EC2 instance, an attacker could feed the tool the instance metadata service address at 169.254.169.254 to retrieve IAM role credentials. Depending on the role's privileges, this could lead to a foothold in the AWS environment and the ability to escalate privileges, move laterally, or to gain additional unauthorized access. The file:// scheme also worked for reading local files from the server.

The recommended fix is to only run the service bound to localhost since authentication is not supported.

CVE-2026-41297: OpenClaw SSRF Vulnerability

A flaw in the OpenClaw marketplace plugin download functionality allowed attackers to access internal resources by following unvalidated redirects, including arbitrary internal or external servers.

Exploitation

We will be discussing one solution in this section. Readers are, of course, encouraged to learn through pain and suffering by trying our otto-support capture the flag (CTF) to remember the lesson more clearly.

In otto-support, SSRF in combination with token passthrough can be used to devastating effect. Existing tools and their capabilities can be used to bypass security functionality at the user tier to access services in unintended ways. A specific API validates a token but forgets to check its audience claim, returning data the user was never authorized to access. The lack of audience claim validation for this CTF was designed one week before OpenClaw was found vulnerable to a similar issue.

Mitigations

SSRF prevention in MCP servers starts with destination validation. The server should resolve the target URL, check the resulting IP address against a blocklist of private and reserved ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, and more), and reject requests accordingly. This check needs to happen after DNS resolution because an attacker-controlled domain can resolve to a loopback address. It also needs to happen after each redirect hop because the initial destination might be legitimate while the redirect target is not.

Beyond blocklists, the MCP server should maintain an explicit allowlist of permitted outbound domains. If the tool is meant to fetch public web pages (untrusted content), it should not be able to reach any internal IP addresses, localhost, or metadata services via IPv4 or IPv6. Network segmentation provides defense in depth here. If the MCP server runs in a network namespace or container with no route to internal services, SSRF does not give the attacker anything useful even if destination validation fails.

Token passthrough should rarely be implemented. Most MCP servers have no legitimate reason to forward a caller's credential to a downstream service. When a downstream API needs authentication, the MCP server should use its own service credential or exchange the caller's token for a scoped downstream token through a mechanism like RFC 8693. The caller's token was issued for the MCP client, not for the payment gateway or the customer API. Forwarding the token violates the audience boundary that OAuth was designed to enforce. If token passthrough is genuinely required for a specific integration, the destinations that receive forwarded tokens must be restricted to an explicit allowlist. The allowlist should contain only the specific services that expect and validate the token format. However, there are likely better ways.

Conclusion

SSRF and token passthrough are not edge cases in MCP environments; they are natural byproducts of how these systems are built, where retrieving data and calling APIs are core features rather than exceptions. As the case studies show, the issue isn’t a single misstep, but a pattern of trusting inputs, destinations, and credentials across boundaries that were never meant to be shared. In otto-support, these weaknesses can be chained to bypass controls and reach services that should be out of scope, reinforcing how quickly small assumptions turn into full compromise paths.

In the next post, we’ll look at another closely related failure mode: the confused deputy problem, where agents act on behalf of a user but unintentionally leverage their authority in ways that break trust boundaries entirely.