An independent security researcher has documented the same server-side request forgery pattern in Model Context Protocol software maintained by Google, JPMorgan Chase, Weaviate, France’s interministerial digital directorate and the city government of Tangerang, Indonesia. All five organizations confirmed and fixed the reported flaws, according to the researcher’s October update.
The individual bugs are familiar web-security failures: unchecked URLs, redirects that can reach internal systems and downstream requests built from untrusted input. What makes them more consequential in an AI-agent stack is where that input can originate. An agent may read hostile instructions from a document, website or tool response, pass the task to another agent over a different protocol, and invoke an MCP server using the second agent’s network position and credentials.
Researcher Syed Anas Mohiuddin calls that cross-protocol attack pattern protocol pivoting. The disclosure does not show one universal flaw in MCP itself, nor evidence that the affected systems were exploited. It does show that mature teams in unrelated organizations repeatedly made the same trust assumption: data arriving from an agent or an internal service was treated as safer than ordinary internet input.
How a malicious instruction crosses agent boundaries
MCP gives an AI application a standard way to discover and call tools. Google’s Agent2Agent protocol and similar systems handle delegation between agents. A production workflow can use both: an orchestrator reads data through one MCP server, assigns part of the job to a specialist agent, and that specialist calls another MCP tool.
The attack begins before any obvious exploit request reaches the vulnerable server. An attacker plants instructions in content the first agent is expected to process, such as a support ticket, document, database record or web page. The model interprets the text and turns it into a delegated task. The receiving agent sees the request as coming from its trusted orchestrator, not from the untrusted content that influenced it.
If the second agent can call a tool that accepts a URL or endpoint without properly validating the destination, it can be induced to request an internal service, a loopback address or a cloud metadata endpoint. The request now originates inside the protected network. Credentials or network access held by the agent and MCP server can turn a prompt-injection attempt into a conventional SSRF attack.
That chain is why patching only the language model is insufficient. Every component may perform its documented function while the combined system loses the origin, authority and risk level of the instruction as it moves between protocols.
The confirmed failures were different versions of the same mistake
The highest-rated issue in Mohiuddin’s set affected Google’s MCP Toolbox for Databases. The HTTP client lacked both a redirect-checking policy and validation of target IP addresses. A crafted path could redirect the server to an internal endpoint. Google assigned CVE-2026-14540 a CVSS score of 8.0 and fixed it by validating resolved addresses, applying IP allow and block lists, checking connections in a way that resists DNS rebinding, and rejecting an unsafe base URL at startup.
JPMorgan Chase’s documentation-search server exposed a subtler fork-related gap. One tool applied a domain allowlist before fetching content, while a sibling function added during a rewrite fetched a caller-supplied URL without that restriction. The bank confirmed the medium-severity report and deployed a fix.
Weaviate constrained configurable Google-module endpoints to approved Google hosts after its report. France’s data.gouv.fr MCP server hardened an external-API fetch that could be redirected through DNS rebinding toward cloud metadata. Tangerang’s Wazuh MCP server had attempted to block SSRF but rejected only literal IP addresses; a hostname resolving to a private or link-local address bypassed the check. Its maintainers published a high-severity advisory and patched the issue.
Rapid7 disclosed a related input-handling failure rather than SSRF. In Bulk Export MCP versions 0.2.5 through 0.6.1, an unvalidated export identifier was interpolated into a GraphQL query. CVE-2026-97228 is rated 2.7 because queries stayed inside the operator’s existing permissions and could not cross tenant boundaries. Version 0.6.2 passes the value as a parameterized GraphQL variable.
“Protocol pivoting” is useful even if the name is disputed
Not every researcher agrees that the behavior needs a new label. Markus Vervier of X41 D-Sec told Ars Technica that it remains indirect prompt injection, with the protocol transition acting as one route for the malicious instruction.
That distinction matters less operationally than the architecture it highlights. Traditional application security reviews often inspect one API, service or code path at a time. Multi-agent systems create chains in which identity, provenance and authorization can be weakened at every handoff. A request that began as untrusted document text may look like an authenticated internal task two agents later.
Dependency scanners also have limited visibility into this class of failure. The dangerous value may arrive as a model-selected tool argument described by a manifest, then cross into HTTP, GraphQL or shell execution. No vulnerable library is required, and a normal static call graph may stop at the protocol boundary.
What MCP teams should review now
The official MCP security guidance already treats SSRF as a first-class risk. It recommends blocking private, loopback and link-local address ranges; applying the same validation to every redirect; defending against DNS rebinding; and using restricted egress proxies in server deployments. The new disclosures show why those controls must apply to tool arguments and cross-agent traffic, not only OAuth metadata discovery.
- Inventory outbound-capable tools. Search every MCP server for URL, host, path, endpoint, repository and webhook arguments. Record which destinations each tool genuinely needs.
- Prefer narrow allowlists. If a tool only talks to Google APIs or one documentation domain, enforce that constraint. A general URL blocklist is easier to bypass and harder to audit.
- Validate after DNS resolution. Reject private, loopback, link-local and reserved addresses, including IPv6 and alternate address encodings. Recheck every redirect hop and protect against time-of-check/time-of-use changes.
- Constrain egress at the network layer. An MCP process that has no business reaching cloud metadata or internal administration services should be unable to route to them, even if application validation fails.
- Parameterize downstream requests. GraphQL, SQL and shell arguments should use structured parameter APIs. Do not build commands or queries by interpolating model-selected strings.
- Carry provenance across delegation. A subagent should know that a task was derived from external content, not merely that it arrived from an approved orchestrator. Sensitive actions should be authorized against the original user and source.
- Give each agent the minimum credentials. Separate tool identities, short-lived tokens and narrow scopes reduce the damage when one task crosses an unexpected boundary.
- Log the chain, not just the final call. Investigators need the source content, orchestrator decision, delegation step, tool arguments and authorization result tied to one trace.
Mohiuddin also reported possible data-leakage issues in five MCP servers associated with U.S. federal services, but those reports remain in triage. He explicitly does not present them as confirmed findings. That caution is important: the strongest evidence here is the set of already acknowledged fixes, not unresolved reports.
The practical lesson is narrower than “do not use MCP.” Treat every value produced or forwarded by a model as hostile input, even when it arrives through an internal agent. MCP and agent-to-agent protocols make delegation easier; they do not make delegated data trustworthy.
