A single security researcher just got five different organizations, including Google and JPMorgan Chase, to confirm the same mistake in servers they built independently. The punchline is that the mistake isn’t exotic: it’s classic server-side request forgery in AI agents connected through the Model Context Protocol (MCP), the open standard that lets AI applications call tools and data sources. What makes it new is where the attacker’s input comes from: not a user, not a network socket, but another AI agent’s output.
One bug, five vendors, zero shared code
Independent researcher Syed Anas Mohiuddin spent the past five months testing MCP servers built by Google, JP Morgan Chase, Weaviate, Rapid7, the French government’s digital directorate (DINUM), and others. The same pattern kept appearing. An MCP server would accept a URL, path, or endpoint from the agent calling it and fetch it without validating where it actually pointed. That’s textbook SSRF, and it usually ends one way: unauthorized requests to internal services or cloud metadata endpoints.
Google’s instance is the most concrete. Its mcp-toolbox HTTP client shipped with no redirect policy and no target IP validation, so a crafted path parameter could force requests to internal endpoints. Google tracked it as CVE-2026-14540, rated 8.0 High under CVSS v4.0, affecting versions 0.3.0 through 1.4.0, and fixed it in v1.5.0 with IP allow and block lists plus a DNS rebinding guard. Rapid7, Weaviate, DINUM, and Indonesia’s Tangerang City government each confirmed and patched their own variants over the summer.
The part that should worry anyone running agents: five MCP servers under the US General Services Administration’s Technology Transformation Services, covering things like Veterans Affairs benefits claims and CMS Blue Button, were reported on September 2 and were still sitting in triage, unfixed, as of the October update.
Why the trust model breaks
Mohiuddin calls the attack class “protocol pivoting.” The setup works like this: agents connected through MCP trust each other by default, and an agent with lax guardrails will happily forward an instruction it received to another internal agent, which executes it because of who sent it. So an attacker doesn’t need to break the target agent’s own defenses. They need to compromise one chatty agent in the middle and let the internal trust do the rest.
The debate over the name is a side show. X41 D-Sec’s Markus Vervier told Ars Technica that “indirect prompt injection” still describes it fine, and Rapid7’s Douglas McKee put the operational point better than anyone: anything passed from an LLM to a tool should be treated like input from a stranger on the internet. Each protocol checks its own front door. Nobody watches the hallway between them.
That framing matters because the underlying bugs are boring. Every one of these is a vulnerability any security team would recognize: SSRF, injection, missing allowlists. The dependency scanners didn’t catch any of them because the dangerous input arrives as a model-chosen tool argument, which no scanner models as an attack path. Anthropic’s own reference fetch server and Microsoft’s playwright-mcp shipped with similar gaps, per disclosures from May. When the reference implementations get it wrong, the ecosystem-wide problem is structural, not a patch queue.
What the fixes actually look like
There’s a silver lining in how small the correct fixes are. Google’s patch validates redirects and target addresses and adds IP allow/block lists. Weaviate restricted its Google module’s endpoint settings to Google API hosts after the field slipped through two earlier hardening passes that only covered a different field. DINUM hardened its open-data MCP server against DNS rebinding and cloud metadata access in a single September pull request.
The recurring lesson: the allowlist you applied to the first fetching tool you wrote needs to apply to every fetching tool, including the sibling tool someone added later. JPMorgan’s case was exactly that, one tool with a domain allowlist next to a related-URL tool that fetched anything the caller supplied.
Mohiuddin has formalized the pattern in an IETF Internet-Draft arguing that the MCP specification defines no normative security requirements, and he’ll present the cross-vendor findings at MCPCon North America on October 23. The draft’s core rule is worth adopting as team policy regardless of what the spec says: treat every tool call parameter as untrusted.
What to do this week
If you operate MCP servers, the checklist is short and old-fashioned:
- Inventory every server that fetches URLs, paths, or endpoints. Confirm it resolves the hostname and validates the resolved IP at connection time, blocks loopback, RFC 1918, and link-local ranges, and doesn’t blindly follow redirects.
- Update googleapis/mcp-toolbox to 1.5.0 or later and Rapid7’s Bulk Export MCP server to 0.6.2 if you run either.
- Constrain the MCP server process itself: least-privilege tool scope, and OS or container level egress rules so a successful SSRF can’t reach cloud metadata.
- Redact upstream response bodies before logging them; several of these bugs leaked credentials through logs.
None of this says agents and MCP are a bad idea. It says the industry is repeating a lesson it already learned about microservices: internal traffic is not safe traffic. Zero trust was invented for exactly this failure mode, and agent architectures abandoned it on day one. The good news is that the fix is ordinary engineering discipline, and now there are five reference implementations to copy from.