MCPStore.nl

Published:

One SSRF pattern in MCP servers from Google, JPMorgan and governments: what 'protocol pivoting' means

In short: researcher Syed Anas Mohiuddin found the same class of flaw in MCP servers from Google, JPMorgan Chase, Weaviate and the French government, among others: URLs and parameters arriving via the AI agent are followed into internal systems without validation (SSRF). Google's MCP Toolbox for Databases received CVE-2026-14540 (CVSS 8.0), fixed in version 1.5.0. According to the researcher, five US government servers remain unpatched.

The research hit the headlines in early October 2026, but it has been in motion for months. Mohiuddin published a preprint on what he calls protocol pivoting in May, reported the flaws privately to the vendors, and posted a technical summary on 29 September. What is new is mainly the scale: not one sloppy hobby server, but official servers from large organisations sharing the same mistaken assumption.

What exactly was found?

The best-documented case is Google's. The CVE description (CNA: Google) states that the generic HTTP source and tool in googleapis/mcp-toolbox versions 0.3.0 through 1.4.0 used an HTTP client without a restrictive redirect policy and without validating the target IP address. An attacker, or according to the description even a malicious data-driven prompt, could supply a path parameter that redirects the request to internal or arbitrary external endpoints. The fix ("implement SSRF guard") was merged on 18 June 2026 and shipped in release 1.5.0 the same day. The CVE record followed on 31 July with a CVSS 4.0 score of 8.0 (high).

According to the researcher and coverage by Unite.AI and The Next Web, these organisations have also fixed a comparable flaw:

Still open, per the same sources, are five US federal MCP servers (covering VA benefits, CMS Blue Button, regulations.gov, USASpending and CDC PLACES) and a Japanese Digital Agency server without authentication. These claims come from the researcher; we found no official confirmation from those governments.

Rapid7 is also named in the coverage, but its case is different. CVE-2026-97228 is a GraphQL injection in the Rapid7 Bulk Export MCP (versions before 0.6.2), scored a low 2.7. The CVE text stresses that an attacker cannot exceed the permissions of the operator's own API key; the realistic risk is a compromised client or indirect prompt injection. The fix landed on 23 September.

Why does this hit MCP servers in particular?

Mohiuddin describes protocol pivoting as an attack that enters through one protocol and exploits the trust between protocols to reach capabilities only available through another. In practice: an agent reads untrusted content (a web page, a ticket, a document), that content steers the agent into a tool call with a chosen URL or parameter, and the MCP server executes it from inside the network. Rapid7's Douglas McKee, quoted by The Next Web, said every piece in that chain did exactly what it was designed to do — which is why it is so hard to catch.

Our take: the shared assumption is that anything coming from "inside" can be trusted. With a classic API, the caller is a program with fixed logic. With MCP, the caller is a model that is steered by whatever text it reads. Every parameter the model fills in is effectively user input of unknown origin. That the same flaw shows up at a bank, a cloud provider and several governments shows this is not one careless team, but a mental model that has not caught up yet.

Our advice

(1) Using Google MCP Toolbox for Databases? Make sure you run 1.5.0 or later. (2) Inventory which MCP servers make network requests based on a URL, endpoint or path the model can influence — fetch, browser, HTTP and integration servers in particular. (3) Enforce the boundary in the network, not just in code: restrict MCP servers' outbound traffic to an allowlist and block private IP ranges and cloud metadata addresses (such as 169.254.169.254). (4) Give the service accounts and API keys behind MCP servers least privilege, so a successful pivot yields little. More in our guide to MCP security, and if you build your own: build an MCP server.

What does this mean for choosing MCP servers?

"Official" does not mean "secure": the Google flaw sat in Google's own server. Where vendors differ is in how they handle it. Google and Rapid7 published CVEs with affected versions and fixes, so scanners pick them up. For servers without a CVE, you have to track releases yourself. For a directory like ours, that is the distinction that matters: not who builds the server, but whether vulnerabilities are handled transparently and quickly. See also our overview of MCP servers for data & analytics.

Sources

Frequently asked questions

Am I affected if I use Google MCP Toolbox for Databases?

Versions 0.3.0 through 1.4.0 are affected by CVE-2026-14540 in the generic HTTP source and tool. Version 1.5.0 (18 June 2026) contains the fix. If you do not use the HTTP source, this specific flaw does not expose you, but upgrading is still wise.

What is SSRF in an MCP server?

Server-side request forgery: the server makes a network request to an address chosen by an attacker (or by a manipulated prompt). Because the MCP server runs inside your network, it can reach internal systems or cloud metadata that are shielded from the outside.

Is this a flaw in the MCP protocol itself?

No. These are implementation bugs in individual servers. The shared pattern is MCP-typical, though: values produced by the model are treated as trusted input and passed to internal systems without checks.

Last updated: