The Same SSRF in Five MCP Servers — Google, JPMorgan and Two Governments Fixed One Researcher’s Finding

2026-10-06 AI Vulnerabilities & CVEs by al-ice.ai Editorial

On 29 September 2026, independent AI security researcher Syed Anas Mohiuddin published a write-up with an unusual claim: over the first nine months of 2026 he had found the same bug shape in MCP servers shipped by Google, Anthropic, Microsoft and Weaviate — four codebases, four languages and frameworks, one shared assumption. This week, in an October research update covered by The Next Web and Ars Technica, the list grew: JPMorgan Chase, France’s interministerial digital directorate (DINUM) and the city government of Tangerang, Indonesia each fixed the same flaw class on his reports, Rapid7 fixed a different bug he found, and five US federal MCP servers — including one handling Veterans Affairs benefits claims — are still carrying open findings in triage.

The May prediction is what makes this more than a bug roundup. Mohiuddin argued the problem was structural: if independent teams sharing no code and no owner all produce the same SSRF, the flaw is in the protocol’s trust model, not in any one implementation. “Watching the same mistake come back from a hyperscaler, a bank, and a national government, one report at a time, is the moment the May argument stopped being a guess,” he wrote. He will present the findings at MCPCon North America in San Jose on 23 October.

The four original cases

Google: the redirect nobody checked. The MCP Toolbox for Databases built its HTTP client with Go’s default redirect-following and no target validation — no CheckRedirect hook, no IP classification. The operator-configured base URL was treated as the whole trust decision, and redirects inherited that trust. Google assigned CVE-2026-14540 (published 31 July 2026, CVSS v4.0 8.0 High, CWE-918), affecting versions 0.3.0 through 1.4.0; the fix landed in June and shipped as v1.5.0, adding redirect and target validation plus a DNS-rebinding guard, with Mohiuddin credited as finder.

Anthropic and Microsoft: the fetch that skips its own guard. The reference mcp-server-fetch and Microsoft’s playwright-mcp both take a URL from the model with no allowlist and no block on loopback, link-local or private ranges. The sharper detail: the fetch server does contain a safeguard, check_may_autonomously_fetch_url() — but the get_prompt handler calls fetch_url() directly and never invokes it. The guard exists; a secondary path walks around it. Mohiuddin published both issues on the Full Disclosure list on 25 May 2026 at CVSS 7.5, writing that he could not confirm fixes as of disclosure. The reference server’s SSRF later received CVE-2026-104120, which we covered separately on 3 October.

Weaviate: the field that dodged two hardening passes. Weaviate had already fixed this bug — twice, in March and June, across 21 URL builders — but both passes were scoped to the field named baseURL. The Google-backed modules spell theirs apiEndpoint, so it sailed through untouched. Worse, the field was settable at query time with ordinary read access, and under USE_GOOGLE_AUTH=true the module attaches a live GCP OAuth token scoped to cloud-platform — meaning a read-access user could point the module at their own host and receive the operator’s cloud credential. Reported via HackerOne, fixed in September in stable/v1.37.

This is the same structural failure as the Grafana prompt-handler file read we covered yesterday: the security control was correctly written and attached to one path into a sink that had two. Mohiuddin names the general shape explicitly — controls get added to the primary tool-call path while prompts, resources and completions, written by someone else on a different day, never route through them.

The October additions

JPMorgan Chase runs an open-source documentation-search MCP server with two tools that fetch content. One checked domains against an allowlist; its sibling fetched any caller-supplied URL. JPMorgan had forked the component from an AWS project that never fetched the caller’s URL at all — the vulnerability was introduced in the fork, not inherited. The bank’s Responsible Disclosure team confirmed the finding and deployed a fix; Mohiuddin rates it medium severity.

DINUM’s official MCP server for France’s open-data platform fetched URLs supplied by data producers, which could point at internal or cloud-metadata addresses. Its fix, titled “harden SSRF on external APIs,” opens with “Reported by Syed Anas Mohiuddin.” In Tangerang’s Wazuh MCP server, a tool advertised SSRF protection but only rejected literal IP addresses — it never resolved hostnames — drawing a high-severity advisory in early September. Rapid7 fixed a different bug he reported, CVE-2026-97228, a GraphQL injection reachable within the operator’s own access that Rapid7 rates low at 2.7 — a reminder that a researcher auditing one flaw class keeps tripping over others.

Still open: five federal servers and Japan

On 2 September, Mohiuddin privately reported issues in five MCP servers under the US General Services Administration’s Technology Transformation Services: Veterans Affairs benefits claims, CMS Blue Button, regulations.gov, USASpending and CDC PLACES. All five remain in triage. The Veterans Affairs case carries an additional data-handling concern: the server logs full, unredacted error responses from the benefits API, which can contain a veteran’s name, Social Security number, date of birth and address. His report on Japan’s Digital Agency grants server, which had no authentication, also remains open. He is withholding code-level detail until maintainers patch — the correct call, and one that puts quiet pressure on the triage queues.

“Protocol pivoting”: MCP output becomes A2A input

The update also names a wider attack class. An attacker plants text in content an MCP tool returns, shaped like a task for Google’s agent-to-agent (A2A) protocol. An orchestrating agent hands it to a subagent, which executes it because it trusts the orchestrator. “Every piece in that chain did exactly what it was designed to do, which is what makes this so tricky to catch,” Rapid7’s Douglas McKee told Ars Technica. X41 D-Sec’s Markus Vervier classifies the technique as a form of indirect prompt injection — which means the cross-protocol hop inherits every unsolved defence problem of prompt injection, now with two protocols’ worth of confused deputies.

Why the same mistake keeps shipping

Line the cases up and the shared assumption is visible: a URL crossed a trust boundary and nobody was standing at the boundary. In a classic web app the attacker types the URL into a form, and every security team knows to distrust it. In an MCP server the attacker plants text somewhere a model will read, and the model types the URL — so the server sees a request from its own trusted model and never asks where the idea came from. The model is not a trusted caller. It is a proxy for every untrusted input it has ever seen, and every URL parameter an MCP server accepts is attacker-controlled by definition.

The fixes that work all share one property: they enforce containment where the request is actually made, not where it is first seen. Google’s redirect-and-target validation, Weaviate’s field-level scoping, hostname resolution before classification rather than literal-IP string checks — and, from our own earlier coverage, re-validating every redirect hop. Mohiuddin found the pattern with tooling, not just eyeballs: mcp-safeguard, his open-source static-analysis scanner for MCP servers, published on PyPI under MIT. If one independent researcher with a scanner can collect a hyperscaler, a bank and two governments in nine months, the servers nobody has scanned yet are not fine — they are unexamined.

What to do

Upgrade Google’s MCP Toolbox for Databases to v1.5.0 or later if you run the HTTP source type; versions 0.3.0 through 1.4.0 carry CVE-2026-14540.
Treat every URL parameter on every MCP surface as attacker-controlled — tools, prompts and resources. Audit the secondary paths; the guard on the primary path does not cover them by osmosis.
Resolve hostnames before classifying, and re-validate each redirect hop. Literal-IP rejection without resolution is theatre, and a base-URL allowlist that redirects inherit is a suggestion.
Scope hardening to behaviour, not field names. Weaviate hardened baseURL twice while apiEndpoint did the same job unguarded. Grep for what a field does, not what it is called.
Never log full upstream error responses unredacted on servers fronting benefits, health or identity APIs — the VA logging detail turns an SSRF-adjacent finding into a PII exposure.
Watch cross-protocol trust. If your orchestrator passes tool output into subagents over A2A, that handoff is an injection boundary — validate or sandbox it like one.

Verification note: we read the researcher’s own write-up (DEV Community, 29 September 2026, originally published on his personal site) for the four-vendor analysis, fix references and severity details, and The Next Web’s 6 October 2026 report for the October update (JPMorgan, DINUM, Tangerang, Rapid7 CVE-2026-97228, the five GSA TTS servers, Japan’s Digital Agency, protocol pivoting and MCPCon). Ars Technica’s contemporaneous report corroborates the disclosure. We did not test any of the servers and did not contact the researcher or the vendors before publication; the federal findings are attributed to the researcher’s reports as covered by TNW.

Sources: