The same SSRF bug turned up in MCP servers at Google, JPMorgan, and two governments

Ars Technica reported on October 6, 2026 that Google and four other organizations have acknowledged the same kind of hole in their Model Context Protocol (MCP) servers. The researcher behind the reports, Syed Anas Mohiuddin, published a follow-up in October titled "Protocol Pivoting, four months later." In May he had predicted that if the weakness were structural, it would appear in servers written by teams that share nothing. It did.

One mistake, five codebases

The mistake is server-side request forgery, usually shortened to SSRF. An MCP server builds an outbound request from an address, path, or endpoint that an agent supplied, and never checks where that address resolves. Whatever the server can reach on its own network, the agent can now reach through it.

The five confirmations came from organizations with different industries, countries, and owners.

• Google: MCP Toolbox for Databases, CVE-2026-14540, affected versions 0.3.0 through 1.4.0, fixed in 1.5.0.
• JPMorgan Chase: the researcher says a documentation-search server's related() tool fetched caller-supplied addresses with no allowlist, unlike its read_documentation sibling. The bank confirmed a fix and rated the case medium.
• Weaviate: the researcher says the Google module's apiEndpoint, region, and location fields could point a request at any host. The fix merged on August 25, 2026.
• France's DINUM: the researcher says the MCP server for data.gouv.fr fetched an address written by the data publisher, server-side and unchecked. The fix merged on September 4, 2026.
• Tangerang City, Indonesia: the researcher says the server's check rejected only literal IP addresses, so a hostname resolving to an internal address walked past it. The fix shipped on September 3, 2026.

The Google case in detail

The GitHub advisory for CVE-2026-14540 rates the bug 8.0 out of 10 on CVSS 4.0, high severity, and was published on July 31, 2026. The toolbox initialized its HTTP client without a CheckRedirect policy and without validating the target IP. A crafted path parameter could make the toolbox follow a redirect to an internal endpoint and send requests on the attacker's behalf.

The fix merged on June 18, 2026 as pull request 3448 and shipped in version 1.5.0. It adds a component called SSRFGuard, rejects an unsafe base address at startup rather than on the first request, and exposes allowPrivateNetworks, allowedIpRanges, and customBlockedIpRanges settings. Mohiuddin calls that what a real SSRF guard looks like, and more work than most MCP servers have done.

Why he calls it protocol pivoting

Mohiuddin's name for the attack class is protocol pivoting: an adversary gains access through one protocol, exploits the trust assumptions between protocols, and escalates to capabilities only reachable through a different one. His worked example puts text shaped like a task for Google's Agent-to-Agent (A2A) protocol inside the output of an MCP tool. An orchestrating agent passes it to a subagent as ordinary delegation, and the subagent runs it because it trusts the orchestrator.

Not everyone accepts the new name. Markus Vervier of X41 D-Sec told Ars Technica that this is indirect prompt injection, and that crossing from one protocol to another is not required for the attack to work. Douglas McKee of Rapid7 told the same outlet that the bugs underneath are old ones, injection and SSRF, and that anything passed from a model to your tool should be treated like input from a stranger on the internet. Rapid7 itself fixed a separate GraphQL injection in its Bulk Export MCP server, CVE-2026-97228, rated 2.7, in September.

What is still open

The researcher says five MCP servers run by the US General Services Administration were reported privately on September 2, 2026 and remained in triage when the follow-up went out. One of them, for veterans' benefits claims, writes full upstream API responses into its logs without redaction, and the researcher says an ordinary validation failure is enough to log a veteran's name, Social Security number, date of birth, and address. He also counts 16 GitHub security advisories that credit him as reporter, two of them with CVE identifiers.

What to check in your own MCP server

If five unrelated teams made the same mistake, it is reasonable to assume the mistake also exists in MCP servers nobody has reviewed. The researcher's list for authors is short.

• Validate the resolved address at connection time, not before it. A hostname can change what it resolves to between the check and the request.
• Turn off automatic redirects, or validate every hop. A redirect to an internal address is the whole attack in the Google case.
• Apply the same allowlist to every tool that fetches, not just the first one you wrote. The JPMorgan case was a second tool that missed it.
• Redact upstream response bodies before logging them. The US federal case is a logging problem, not a fetching one.