In the first week of October 2026, independent security researcher Syed Anas Mohiuddin published a research update with an uncomfortable tally: the same flaw in Model Context Protocol (MCP) servers had been confirmed — and fixed — by the security teams of Google, JPMorgan Chase, Weaviate, France’s interministerial digital directorate, and the city government of Tangerang, Indonesia. Two CVEs have been published. Five findings in US federal MCP servers are still open.
This is not a story about one vendor’s sloppy code. It is a story about trust — who trusts whom in an agent pipeline, and what that trust lets an attacker do.
Two trust problems surfaced in the same week
Problem one: servers trust agent-supplied URLs. Mohiuddin’s October update, titled “Protocol Pivoting, four months later,” tested a prediction he made in May 2026: if the weakness were structural rather than a single careless implementation, the same bug would surface in servers written by teams sharing no code, industry, country, or owner. It did. The failure mode is server-side request forgery: an MCP server builds an outbound request from a URL, path, or endpoint supplied by an agent, without checking where it resolves — so the agent effectively decides what the server’s network identity talks to.
Google’s case was the most severe, rated 8 out of 10. Its MCP toolbox for databases initialized its HTTP client with no redirect policy and no validation of target IP addresses. A crafted path parameter could make the toolbox follow a redirect to an internal endpoint and send requests on the attacker’s behalf. Google’s fix is instructive: an allow-list of IP ranges plus block lists, rejecting an unsafe base URL at startup instead of on first request.
Problem two: agents trust each other’s messages. Separately, a proof-of-concept reported this week demonstrated the chain-of-trust gap inside multi-agent networks: compromise a single agent, and you can relay a suspicious instruction — one the LLM would normally intercept — disguised as a trusted internal message. It sails through, because every downstream agent trusts the handoff.
Douglas McKee, Rapid7’s director of vulnerability intelligence, put it plainly to Ars Technica: “Someone plants text in content, an agent will read it then pass it along to another agent as a normal delegated task, and that second agent runs it because it trusts whoever handed it the work. Every piece in that chain did exactly what it was designed to do, which is what makes this so tricky to catch. Each protocol was built assuming it lived on its own, so each one checks its own front door while nobody watches the hallway in between.”
Why this is structural, not a bug
Mohiuddin generalized the pattern into an IETF Internet-Draft (draft-mohiuddin-mcp-security-considerations-00) describing six vulnerability classes under one name: protocol pivoting — the attacker enters through the model-facing protocol and pivots into whatever the server can reach behind it. The root assumption, in his words, is that data crossing the MCP boundary is trusted because it came from inside the system. In an agentic pipeline, that assumption does not hold.
The scale backs him up. Academic MCPInspect research (presented at DSN 2026) built a pre-integration scanner and found 833 vulnerable MCP servers — 18 of them with suspicious or misleading tool descriptions, suggesting deliberate attempts to poison agent behavior at the supply-chain level. This is not just accidental exposure; parts of the ecosystem are being actively seeded.
The question most coverage skips: what could a poisoned instruction actually do?
Here is the part that matters for anyone building on MCP. Take the same poisoned instruction arriving at two different servers:
- Server A exposes write tools: move funds, modify records, call internal endpoints (via the SSRF above), exfiltrate data through logging.
- Server B exposes only read-only data lookups: the worst case is a wrong answer or a wasted API call.
The protocol flaw is identical. The blast radius is a design decision. Patching closes today’s hole; tool design decides what the next hole costs you. The official MCP Security Best Practices (July 2026) and NSA guidance (June 2026) both land in the same place: defense in depth, least privilege — and, explicitly, split read and write tools.
Operator checklist for this week
If you run agents in production, this is the short list worth acting on now:
1. Treat every tool output as untrusted input — especially in multi-agent setups where messages hop between agents.
2. Don’t share one deployment across vendors’ agents. A compromised agent anywhere in the mesh can speak for the mesh.
3. Split read and write tools, minimize scopes, and require explicit user consent for anything side-effecting.
4. Put egress controls on your MCP servers — proxies, allow-lists. Google’s fix is the template: reject unsafe destinations at startup, not when the request fires.
5. Pin versions and pre-scan servers before adding them to an agent’s toolset. Watch for tool descriptions that don’t match what the tool does.
6. Log the full chain — prompt → tool call → downstream action — so you can reconstruct an incident instead of guessing.
Our posture: read-only by design
We build the Pangolinfo Amazon Data MCP server, so here is exactly where we stand:
- Read-only. Every tool is a strictly read-only data lookup — product, search, review, seller, and category data. None of them can write to Amazon, place orders, post reviews, modify listings, or take any side-effecting action on third-party platforms.
- Bring your own key. Your API key is read locally from your client config and sent only to Pangolinfo hosts over TLS 1.2+. We never concentrate anyone else’s credentials.
- No telemetry, no PII collection. The server does not phone home, log your prompts, or persist account info.
- Open source (MIT). Anyone can audit what the server sends and where. Report issues privately to [email protected].
For setup instructions and the full tool reference, see the Amazon Data MCP documentation.
And the chain-of-trust point, stated directly: MCP agents trust each other by default — independent researchers have shown (October 2026) that a compromised agent can relay a malicious instruction disguised as a trusted internal message. Our exposure is limited by design: a poisoned instruction routed through this server cannot write, transact, or reach third-party services. If you run multi-agent setups, treat tool outputs as untrusted input and don’t share one deployment with agents from other vendors.
One honest caveat: read-only bounds the blast radius; it does not make data-integrity attacks impossible. A compromised upstream could still return false data, and no server-side design fixes that — only out-of-band verification does. We would rather say that plainly than sell a silver bullet.
Bottom line
Audit the MCP servers you run. Assume the trust chain will surprise you again — the researchers are telling us, nearly in real time, that it will. And design the tools you build so the surprise costs you a wrong answer, not a wrong action.
— The Pangolinfo team
Sources
- Unite.AI — “Researcher Discloses Same MCP Flaw at Google, JPMorgan, Two Governments”: https://www.unite.ai/researcher-discloses-same-mcp-flaw-at-google-jpmorgan-two-governments/
- Real Hacker News (summarizing Ars Technica) — “MCP for agent-to-agent comms may be the riskiest protocol you’ve never heard of”: https://realhacker.news/mcp-for-agent-to-agent-comms-may-be-the-riskiest-protocol-youve-never-heard-of/ (Ars original: https://arstechnica.com/security/2026/10/ai-agent-frameworks-trust-chain-is-broken-rapid7-researcher-warns/)
- Syed Anas Mohiuddin (dev.to) — “Four vendors, one bad assumption: SSRF in MCP servers”: http://dev.to/syedanas01/four-vendors-one-bad-assumption-ssrf-in-mcp-servers-48ii
- AI Daily Post — “MCP Agent Protocol Flaw Exposes Chain-of-Trust Risk”: https://aidailypost.com/news/mcp-agent-protocol-raises-chain-of
- Forkast — “MCP Security: Attack Surface, CVEs, and Mitigations”: https://forkast.news/glossary/mcp-security/
