MCP Server SSRF Vulnerability Exposed: Google, JPMorgan Chase Among Five Organizations Affected

An Overlooked Security Blind Spot: The SSRF Problem in MCP Servers

When an AI Agent needs to fetch external information, it typically initiates requests through an MCP (Model Context Protocol) server. The problem: if the server blindly trusts the address passed in by the Agent, an attacker can make the server access internal resources it was never meant to reach.

According to a report by TNW this month, Google, JPMorgan Chase, Weeviate, France's Digital Directorate, and a municipal government in Indonesia each patched the same class of vulnerability in their MCP servers — server-side request forgery (SSRF). Google rated its version as high severity.

These organizations' MCP servers constructed outbound requests directly using the address provided by the Agent, without verifying where that address actually resolved to. Attackers could exploit this to make the servers access internal networks, cloud metadata endpoints, or other sensitive resources.

Why SSRF Is Especially Dangerous in the MCP Context

SSRF in traditional web applications is already tricky enough, but the unique characteristics of MCP servers amplify the problem further.

An MCP server is essentially a "proxy execution layer": the Agent handles reasoning and decision-making, while the server handles actually initiating network requests. This means the server has more direct network access capabilities than a typical API gateway. Once address validation is missing, the server can become a springboard for attackers to enter the internal network.

What makes it worse is that Agent requests tend to be dynamic — the Agent decides on the fly what resource to fetch based on conversation context. This flexibility makes it difficult for static allowlists to cover all legitimate scenarios, and developers are prone to loosening validation for convenience.

The core mechanism of SSRF (Server-Side Request Forgery) is that the attacker does not directly access the target resource, but instead induces a server-side component with network access privileges to initiate the request on their behalf. Typical consequences include probing internal network topology, reading instance metadata endpoints in cloud environments (such as AWS's 169.254.169.254, which may contain temporary credentials), and accessing admin panels or databases only exposed to the internal network. Historically, the 2019 Capital One data breach was linked to SSRF combined with a metadata endpoint, resulting in the exposure of over a hundred million users' information.

The key challenge in defending against SSRF lies in the consistency between validation timing and validation targets. Common practices include: resolving the target domain to an IP and then determining whether it falls within restricted ranges such as private address blocks (RFC 1918), link-local addresses, and loopback addresses; restricting protocols to only http/https; and re-validating after every redirect. DNS Rebinding is another bypass technique — the attacker has the domain resolve to a legitimate public IP the first time to pass validation, then switches to an internal IP. So if there's a time gap between resolution and connection, validation can be defeated.

Five Organizations, the Same Mistake

These five organizations differ in size, industry, and geography, yet they all fell into the same trap.

According to TNW, all of these vulnerabilities were discovered and reported by a single independent security researcher, Syed Anas Mohuddin. He publicly disclosed the details this month.

From Google to JPMorgan Chase, to French government agencies and Indonesian local governments, this shows that it's not the negligence of any single team, but a widespread design blind spot in the MCP ecosystem. When everyone is rapidly building Agent infrastructure, security often takes a back seat to functionality.

Google rating the SSRF vulnerability in its MCP server as "high severity" also corroborates the real-world impact of this class of problem.

The Core Logic of the Fix

The fix itself is not complicated: MCP servers must resolve and validate the target address themselves before initiating outbound requests.

Specifically, the server needs to check whether the target address resolves to internal IP ranges, cloud metadata endpoints, or other restricted resources. Extra caution is needed with redirects, because a single 302 redirect can bypass the initial validation.

As the original article summarizes: "A tool that fetches things for an Agent must check the destination itself." This statement captures the core principle of MCP server security design — the trust boundary cannot be outsourced.

MCP (Model Context Protocol) is a protocol open-sourced by Anthropic in November 2024, used to establish standardized connections between AI models and external tools and data sources. It adopts a client-server architecture: the MCP client on the Agent side handles interaction with the model and tool invocation, while MCP servers expose specific resource access capabilities (reading/writing files, querying databases, calling HTTP APIs, etc.) in the form of "tools."

The value of this design lies in decoupling — tool implementers don't need to care about model details, and Agents don't need to write custom code for each data source. But it simultaneously introduces a new trust boundary: the Agent's reasoning process can be manipulated by prompt injection attacks, generating malicious request parameters. Therefore, MCP servers must treat parameters from Agents as untrusted external input, rather than assuming they're safe just because "the request comes from our own Agent." This is precisely the cognitive bias exposed by this batch of vulnerabilities.

Cloud metadata endpoints are internal services provided by cloud vendors that supply configuration and credential information for running instances, with the typical address being 169.254.169.254 (AWS, Azure, GCP, and others generally use similar addresses). They don't go through the public internet and are only reachable from within the instance, which is why SSRF attackers often target them first — once the instance role's temporary credentials are read, attackers may be able to pivot laterally to other resources within the cloud account.

Some cloud vendors have introduced protective measures, such as AWS's IMDSv2, which requires requests to carry a token obtained via PUT and limits the hop count, significantly raising the difficulty of SSRF exploitation. But for MCP servers, the more fundamental approach is still to uniformly intercept all targets pointing to link-local addresses, private network ranges, and loopback addresses before outbound requests, and to validate redirects hop by hop.

Implications for Developers

The concentrated exposure of this batch of vulnerabilities serves as a reminder for teams currently building Agent applications.

MCP servers are not simple HTTP forwarders — they bear the responsibility of security gatekeeping. Any address passed in by an Agent should be treated as untrusted input and must go through a complete process of resolution, validation, and redirect restrictions.

At the same time, this also exposes the lack of security standards in the current MCP ecosystem. When the protocol itself doesn't mandate address validation, the security bar varies across implementations. As more and more enterprises connect MCP servers to production environments, establishing a unified security baseline will become increasingly urgent.

For independent researchers, Syed Anas Mohuddin's work also demonstrates: when different companies make the same mistake, it means systemic security issues deserve continuous scrutiny.

One-line Summary

Five organizations' MCP servers exposed to the same class of SSRF vulnerability, revealing a systemic security blind spot in Agent infrastructure.

Paragraph Summary

The article reports that Google, JPMorgan Chase, Weeviate, France's Digital Directorate, and an Indonesian municipal government patched SSRF vulnerabilities in their MCP servers, all five discovered by a single independent researcher, Syed Anas Mohuddin. The root cause is that MCP servers used addresses passed in by Agents to initiate outbound requests without validating where those addresses actually resolved, allowing attackers to access internal networks, cloud metadata endpoints, and other sensitive resources. The article analyzes the particular dangers of SSRF in the MCP context — servers as proxy execution layers have stronger network access capabilities, and Agent requests are dynamic, making static allowlists difficult to cover. The core fix is that servers must resolve and validate target addresses themselves, and guard against redirect bypasses, while calling for the MCP ecosystem to establish a unified security baseline.