MCP Servers Keep Making the Same Mistake: SSRF and "Protocol Pivoting"

Over the past several months, security teams at Google, JPMorgan Chase, Weaviate, France's interministerial digital directorate (DINUM) and a city government in Indonesia have each fixed the same kind of bug in their Model Context Protocol (MCP) servers. One independent researcher, Syed Anas Mohiuddin, reported all five. The bug is server-side request forgery, or SSRF. Source

The organizations have little in common. They did not share code or an owner. That is the interesting part. When unrelated teams make the same mistake, the cause is usually the design pattern, not the people. Ars Technica reported the story on October 5 under the headline that the findings expose a structural flaw in MCP. Source

If your company builds or buys AI agents that call tools, this is worth a short read. Below we cover what SSRF means here, what the primary records confirm, where the reporting is thinner, and what a team can do this week.

What SSRF means for an MCP server

MCP is the standard many AI agents use to call tools and data sources. An MCP server often takes a URL, a path or an endpoint from the agent and builds an outbound request from it. SSRF happens when the server does that without checking where the address really points. Whoever can steer the agent can then steer the server toward internal systems. Source

The risk is higher with agents because the "caller" is a language model, and a language model can be steered by text it reads. A web page, a document or a tool result can carry instructions. If those instructions end up inside a URL or path that a tool passes to an HTTP client, the server may fetch something nobody intended.

The confirmed example: Google's MCP Toolbox

The best documented case is Google's MCP Toolbox for Databases. The public vulnerability record, CVE-2026-14540, says the generic HTTP source in versions 0.3.0 through 1.4.0 had an HTTP client with no restrictive redirect policy and no validation of target IP addresses. A crafted path parameter could trigger an open redirect or a direct destination swap, so the toolbox would make requests to internal or arbitrary external endpoints. Source

Google's fix is public. Pull request 3448, merged on June 18, 2026, adds an SSRF guard to the HTTP source. It protects against DNS rebinding, adds settings for allowed and blocked IP ranges and private networks, and checks the configured base URL when the server starts. The pull request credits Mohiuddin. Source

One note on severity. Scores for this CVE differ by scoring system: the Tenable listing shows 6.1 under CVSS v3 and 9.3 under CVSS v4, and press coverage quotes a rating of 8.0. We do not pick one number here. Read the record for the version that your own risk process uses. Source

The other reported cases

The Next Web summarizes the rest, citing Mohiuddin's own write-up. We could not retrieve that write-up directly, so treat these details as secondary reporting. Source

• JPMorgan: a documentation-search MCP server had two fetch tools. One checked domains against an allowlist. The other fetched any URL the caller supplied. JPMorgan's disclosure team confirmed and fixed it, and the reported severity is medium.

• Weaviate: it restricted its Google module's endpoint settings to Google API hosts.

• DINUM: the official MCP server for France's open-data platform fetched URLs supplied by data producers, which could point at internal or cloud metadata addresses.

• Tangerang city government: a Wazuh MCP server advertised SSRF protection but only rejected literal IP addresses and never resolved hostnames.

That last case is a good lesson on its own. A check that looks at the text of a URL is not the same as a check on where the connection goes. A hostname can resolve to an internal address.

A correction worth making: the Rapid7 bug

Some coverage groups a Rapid7 finding with the SSRF cases. Rapid7's own database entry describes something different. CVE-2026-97228 is a GraphQL query injection in the Rapid7 Bulk Export MCP server, in the export-status component. An unvalidated tool argument was placed directly into a GraphQL query string. The fix, in version 0.6.2, passes it as a parameterized variable instead. Source

Rapid7 rates it 2.7, which is low, and says it gives no actor access they did not already have, because injected queries run inside the operator's own authenticated scope. It names indirect prompt injection forwarding an unvalidated identifier as the realistic exposure. The family resemblance is real: an agent passes untrusted text into a tool argument, and the tool trusts it. The class of bug is different, and the severity is low. Source

"Protocol pivoting": useful name, open debate

Mohiuddin calls the wider attack class "protocol pivoting." As Ars Technica describes it, an attacker gains a foothold through one protocol, uses trust between protocols, and reaches capabilities that only another protocol exposes. An example is text planted in a tool result that is shaped like a task for Google's Agent-to-Agent (A2A) protocol. An orchestrating agent hands it to a subagent, which runs it because it trusts the orchestrator. Source

Not everyone agrees the term adds much. Markus Vervier of X41 D-Sec told Ars that the better name is still indirect prompt injection, and that the cross-protocol angle is not required for such attacks to work. Douglas McKee of Rapid7 gave the practical advice most teams need: treat anything passed from a language model to your tool like input from a stranger on the internet. Source

We agree with that framing. Whatever the name, the fix is old and boring: validate inputs, limit what each component may reach, and do not assume that a message from another agent is safe.

Why this is an AgentOps problem

Most agent security talk centers on the model. These cases center on the glue: the tool servers, their HTTP clients, their credentials and the trust between agents. The reporting notes that MCP servers hold credentials for each agent, and that many special-purpose agents have weak guardrails, so an instruction a language model would refuse can still succeed further down the chain. Source

That makes it an operations question. Who owns each MCP server? Which network can it reach? What credentials does it hold? What gets logged? These are the questions an AgentOps practice should answer before an incident.

A checklist for teams running MCP servers

These steps are our recommendations, drawing on the fixes described above.

1. Inventory your MCP servers. List every server your agents can call, including open-source ones copied into internal repos, and the owner of each.

2. Update the ones with published fixes. If you run Google's MCP Toolbox, check that you are past version 1.4.0. Source

3. Resolve, then check. Validate the IP address a hostname resolves to at connection time, not just the text of the URL. This is the point of Google's DNS rebinding protection. Source

4. Restrict redirects. Set a redirect policy on every HTTP client and re-check the destination after each hop.

5. Block internal and metadata ranges by default. Open them only where a tool truly needs them, with an explicit allowlist.

6. Give each server a narrow network path. Egress rules should limit where a tool server can connect, so one mistake cannot reach your whole network.

7. Scope credentials per tool. A server that only reads one dataset should not hold keys for everything.

8. Parameterize, never concatenate. Treat each tool argument as untrusted input, as the Rapid7 fix does. Source

9. Log tool calls and outbound requests. You cannot investigate a pivot you did not record.

10. Test with hostile content. Put adversarial text in a document or web page your agent reads and see what your servers fetch.

Where Codesprint fits

We help teams move agents from demo to production, including the layer around the model: tool servers, permissions, network limits, credentials and logging. Our AgentOps services cover that work. If you want a second look at how your agents reach internal systems, contact us.