iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A security researcher says five organizations fixed server-side request forgery (SSRF) flaws in their Model Context Protocol (MCP) server implementations: Google, JPMorgan Chase, Weaviate, France’s interministerial digital directorate (DINUM), and the government of Tangerang City, Indonesia. The cases share a risk pattern—an MCP server making a network request to a destination influenced by an agent or tool input—but they are separate implementation findings, not one vulnerability in the MCP protocol itself. The details below are reported by Unite.AI on October 5, 2026, based on researcher Syed Anas Mohiuddin’s account; the primary advisories and code changes were not independently verified here.
What the reported MCP flaw allows
Server-side request forgery happens when a server is induced to make a request to a destination chosen or influenced by an outside party. In the reported MCP cases, an agent or tool input could supply a URL, endpoint, or related value that the server then used for an outbound request without adequately restricting where that request could go.
Because the request comes from the server, it may reach systems or network locations unavailable to the agent directly. Depending on the server’s environment and the flaw, destinations could include internal services, loopback or private-network addresses, cloud metadata endpoints, or arbitrary external hosts. That describes the risk class; it does not establish that every reported case exposed all of those targets.
“The same flaw” is best understood as a recurring SSRF pattern across independently maintained projects. The report does not establish that the projects shared code or that the MCP specification itself contains an SSRF vulnerability. Mohiuddin’s broader argument is that agent-facing server implementations can repeat unsafe assumptions about caller-controlled destinations.
#1 Best Overall
Which organizations reportedly fixed an SSRF finding?
Unite.AI’s October 5, 2026 account says the researcher’s findings were confirmed and fixed by all five organizations below. Specific versions, remediation details, and disclosure status in this table are claims attributed to that account, rather than independently verified advisory findings.
| Organization or project | Reported issue and remediation |
|---|---|
| Google MCP Toolbox | The report says generic HTTP source and tool components in versions 0.3.0 through 1.4.0 were affected, identifying CVE-2026-14540 and a reported CVSS score of 8.0. It says the fix shipped in version 1.5.0 and included an SSRF guard, destination-IP checks, configurable network restrictions, and validation of the configured base URL. |
| JPMorgan Chase | A documentation-search MCP server reportedly restricted domains for one tool but let a related tool fetch a caller-supplied URL without the same restriction. The report says the bank’s responsible-disclosure team confirmed the finding and deployed a fix. |
| Weaviate | The account describes a change restricting Google module endpoint, region, and location settings to Google API hosts. It also says Mohiuddin appeared in a public security-recognition entry. |
| France’s DINUM / data.gouv.fr MCP project | A producer-supplied documentation URL reportedly could target loopback, private-network, or cloud metadata addresses. The account identifies DNS rebinding and redirects as additional concerns, and says the fix validated destination IPs at connection time, checked redirect hops, and refused proxies. |
| Tangerang City government, Indonesia | The report says a protection check rejected literal private IP addresses but did not resolve hostnames that pointed to private, loopback, or link-local addresses. It reports that a patch was applied and credits Mohiuddin as the reporter. |
Why hostname and redirect checks matter
Blocking a URL because its hostname looks acceptable is not always enough. A hostname can resolve to a private or loopback IP address, and DNS rebinding can make the address differ between an initial check and the later connection. A redirect can also send a request somewhere different from its original destination. The DINUM and Tangerang cases, as described in the report, illustrate why checks need to account for the actual destination IP and every redirect hop—not just the text of the submitted URL.
The reported cases point to several useful questions when assessing an MCP server’s outbound-request policy:
- Does it resolve hostnames and reject private, loopback, link-local, and other restricted address ranges?
- Are destination checks applied at connection time, so a DNS change cannot invalidate an earlier check?
- Is each redirect destination checked again?
- Can a proxy route requests around the server’s restrictions?
- Are outbound destinations restricted to an explicit allowlist where the tool’s purpose permits it?
These are security-review considerations drawn from the reported remediation examples, not a claim that the report established a complete or uniform test of all five projects.
Rank #3
Other findings in the account are separate issues
Rapid7 Bulk Export MCP: GraphQL injection
The report separately describes GraphQL query injection in Rapid7 Bulk Export MCP, associated with CVE-2026-97228. It says versions 0.2.5 through 0.6.1 were affected and version 0.6.2 fixed the issue; it also characterizes the impact as limited to the operator’s own API scope. This is a different vulnerability class and is not one of the five SSRF cases.
Five federal findings: private triage, not confirmed outcomes
Mohiuddin reportedly said five findings in U.S. federal MCP servers remained in private triage and were not confirmed as fixed. The account mentions a concern about upstream benefits API error bodies being written to logs without redaction, but says further code-level detail was withheld. These should not be described as confirmed vulnerabilities or resolved incidents.
Microsoft playwright-mcp: an earlier, unconfirmed concern
The article also recounts a prior concern involving agent-supplied navigation URLs in Microsoft playwright-mcp and possible access to instance metadata. It reports no CVE or vendor confirmation and presents the severity as the researcher’s own assessment. That case is distinct from the five reported, confirmed-and-fixed findings.
Recommended Free Tools
What Mohiuddin means by “Protocol Pivoting”
“Protocol Pivoting” is Mohiuddin’s term for an attack that begins through one protocol and exploits trust between protocols to reach capabilities exposed through another. In the example summarized by Unite.AI, instruction-like text appears in MCP tool output; an orchestrator then passes it to an A2A subagent as ordinary delegation, and that subagent acts on it. The term is not presented as a formal standards definition, and this cross-protocol scenario is not itself an SSRF vulnerability.
The report says a preprint with that title was published on Zenodo on May 24, 2026, and describes three scenarios: MCP-to-A2A privilege escalation, A2A-to-MCP capability injection, and cross-protocol prompt-injection chains. The preprint’s details are not independently assessed here.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
