If your team builds AI agents for clients, MCP security just became a real line item. On October 5, 2026, Ars Technica reported that an independent researcher found the same kind of flaw in MCP servers run by Google, JPMorgan Chase, Weaviate and two governments. The teams share no code. They share a protocol.

MCP, short for Model Context Protocol, is the standard many AI apps use to connect agents to tools and data. I read the Ars report and the researcher's own write-up line by line. Here is what was found, why it matters for agencies in India and the USA, and what we are changing in our own builds.

Rows of small cartoon robot heads on glowing platforms connected by circuit lines, representing networked AI agents — AI agents increasingly hand work to each other, and that trust is where attackers look. Image: Getty Images via Ars Technica

What the MCP Security Research Found

The story comes from Ars Technica's report on protocol pivoting in MCP, written by Dan Goodin. It covers work by Syed Anas Mohiuddin, an independent security researcher with no employer or lab behind him.

In May 2026, Mohiuddin argued that a common MCP bug was structural, not a one-off mistake. Since then, he says, five separate security teams have confirmed and fixed the same problem in their own servers.

The organisations involved

According to Mohiuddin's protocol pivoting update, the confirmed server-side request forgery (SSRF) fixes came from:

Google: its MCP Toolbox for Databases, tracked as CVE-2026-14540 with a CVSS score of 8.0.
JPMorgan Chase: a documentation-search MCP server in its open-source payments repository.
Weaviate: the vector database company restricted a configurable Google API endpoint.
DINUM: the French government's digital directorate, which runs the official MCP server for data.gouv.fr.
Tangerang City government in Indonesia: a Wazuh security operations MCP server.

Rapid7 also published CVE-2026-97228 for a related bug in its Bulk Export MCP server. That one was a GraphQL query injection rated 2.7 out of 10, and it was fixed in version 0.6.2.

Mohiuddin has also reported issues in five MCP servers built for the US federal government. He filed them on September 2, 2026. They are still in triage, and he is careful not to present them as confirmed.

The Google bug in plain words

Google's toolbox set up its HTTP client without a redirect policy. It also did not check which IP address a request actually reached. A crafted path parameter could make the server follow a redirect to an internal endpoint.

In other words, an outside party could get the server to make requests on their behalf, from inside the network. That is classic SSRF. Google's fix checks resolved addresses at connection time, applies allow and block lists for IP ranges, and rejects an unsafe base URL at startup.

How Protocol Pivoting Works

Mohiuddin calls the wider attack class "protocol pivoting." It matters because real agent systems rarely use one protocol. They often use MCP for tools and Google's Agent-to-Agent (A2A) protocol for handing tasks between agents.

Here is the chain he describes, step by step:

An attacker plants text in content that an MCP tool returns, such as a web page or a document.
The text looks like a task instruction. The main agent reads it and passes it to a helper agent as normal delegated work.
The helper agent trusts the main agent, so it runs the instruction without question.
If the helper holds a flawed MCP server, the harmful request now starts inside your trust boundary, with that agent's permissions.

No single part was hacked in the usual sense. Each part did what it was built to do. Douglas McKee, director of vulnerability intelligence at Rapid7, put it well to Ars: "each one checks its own front door while nobody watches the hallway in between."

Diagram showing AI applications such as chat interfaces and code editors connecting through the MCP standard protocol to data sources, development tools and productivity tools — MCP sits between AI applications and the tools and data they use, so every connection is a place where trust must be checked. Diagram: Model Context Protocol documentation, via Ars Technica

Is this just prompt injection?

Not everyone likes the new name. Markus Vervier of X41 D-Sec told Ars that he sees it as indirect prompt injection, and that the cross-protocol part is not strictly needed. That view lines up with the OWASP guidance on prompt injection, which ranks it as the top risk for apps built on large language models.

For agency teams, the label matters less than the lesson. Any text an agent reads can carry instructions. Any agent that trusts another agent blindly can carry them further.

Why MCP Security Matters for Agencies in India and the USA

Agencies are building a lot of agent work right now. Support bots read tickets. Sales agents read CRM records. Internal tools fetch documents, query databases and call client APIs. Many of these run on MCP servers, some written in a weekend.

The research points to three risks we see in real client projects.

1. Forked code loses its safety checks

The JPMorgan case is the most useful one for developers. Its server was forked from an AWS project. The AWS original never fetched the caller's URL at all. JPMorgan's rewrite added a fetch for one tool but left out the domain allowlist that its sibling tool had.

Two good teams, one routine fork, and a gap neither original had. Agencies fork open-source MCP servers all the time. That makes this the bug pattern most likely to show up in your repo.

2. Scanners do not see the problem

Mohiuddin makes a point that should worry delivery leads. Dependency scanners look for known bad packages and follow code paths. In an MCP server, the risky input arrives as a tool argument the model picked. The scanner never models that path.

So a clean scan report does not mean a safe MCP server. You still need a person reading how each tool treats its inputs.

3. Logs can leak personal data

The federal findings show a second failure mode. Mohiuddin says one benefits server logged full upstream error responses without redaction. Those responses could include names, Social Security numbers and addresses. Ordinary errors were enough to trigger it.

For agencies serving healthcare, finance or government clients in the USA, that is a compliance problem. In India, the Digital Personal Data Protection Act raises the same concern for personal data in logs.

A Practical MCP Security Checklist

The good news is that the fixes are not new. As McKee told Ars, the bugs underneath are old friends like injection and SSRF. Here is the checklist we now apply to every MCP server we build or adopt.

Treat every tool argument as untrusted

Validate every value that comes from an agent, the same way you would treat a form field from a stranger.
Use parameterised queries. Rapid7's fix passed the export ID as a GraphQL variable instead of pasting it into the query string.
Never build shell commands or file paths directly from tool arguments.

Lock down outbound requests

Apply one allowlist to every tool that fetches, not just the first one someone wrote.
Check resolved IP addresses at connection time, so DNS tricks cannot swap the target after your check.
Turn off automatic redirects or validate every hop.
Block private, loopback and cloud metadata addresses such as 169.254.169.254.

Give agents less trust and fewer powers

Do not let agents trust each other by default. Require checks before sensitive actions, in line with the zero trust model in NIST SP 800-207.
Scope credentials per agent and per tool. A translation agent does not need database write access.
Add a human approval step for payments, deletions, emails to customers and production changes.

Clean up logging and testing

Redact upstream response bodies before they reach central logs.
Diff forked servers against the original and list every check that changed.
Add MCP tools to your security testing scope. Our guide to AI penetration testing for agency teams covers how to plan this.

If you are still deciding whether MCP fits a project, our earlier post on when to avoid MCP in Claude Code workflows walks through the tradeoffs.

What This Looks Like on a Real Project

Picture a support agent built for a US ecommerce client. It reads customer emails through one MCP tool. It hands refund checks to a second agent over A2A. That second agent has an MCP server that fetches order data from a URL.

A customer email includes hidden text shaped like a task. The first agent passes it along. The second agent fetches a URL the attacker chose, maybe an internal admin page or a cloud metadata endpoint. Nobody wrote malicious code. The design simply trusted the wrong thing.

Now apply the checklist. The fetch tool only reaches the order API's host. Private addresses are blocked. The refund agent cannot act without a signed request from the orchestrator. The attack stops at step two.

Weak point	What can go wrong	Simple fix
URL tool arguments	SSRF to internal services	Host allowlist and IP checks at connect time
Agent-to-agent trust	Planted instructions spread	Authorisation before sensitive tasks
Query strings	Injection into databases or APIs	Parameterised queries
Error logging	Personal data in logs	Redact bodies before logging
Forked servers	Dropped safety checks	Diff against upstream and review

What Comes Next for MCP Security

Mohiuddin says he will present the cross-vendor pattern at MCPCon North America in San Jose on October 23, 2026. He has also released an open-source scanner, though he admits that pattern-matching tools miss a large share of this bug class.

Expect more disclosures. MCP servers are being published faster than anyone reviews them. For clients, the smart move is to ask vendors and agencies how their MCP servers handle inputs, before an incident forces the question.

If you want a second pair of eyes on an AI agent build, our software development consulting team can review your MCP setup and help you plan fixes.

Key Takeaways

Five organisations fixed the same SSRF flaw in their MCP servers, including Google, JPMorgan Chase and the French government.
Protocol pivoting moves planted instructions from one agent to another through trusted handoffs.
Scanners miss it because the risky input arrives as a tool argument chosen by the model.
Forks are a common source of dropped safety checks.
The fixes are familiar: input validation, allowlists, IP checks, least privilege, redacted logs and zero trust between agents.

About the Author

Nitin Kumar is the Lead Project Coordinator at Debugged Pro. He coordinates development and QA teams delivering web platforms and AI integrations for clients across India and the USA, and he follows security research closely so client builds stay safe.