One bug, five organizations: the hallway problem has a name
Sources cited in this piece · Ars Technica security report, 5 Oct 2026, quoted verbatim via syndicated coverage (Times of AI) · research-update framing and chain-of-trust analysis via Pangolinfo (quoted verbatim) · IETF Internet-Draft draft-mohiuddin-mcp-security-considerations-00 (referenced) · MCPInspect study, DSN 2026 (referenced). The independent researcher is cited here by work, not by name; organizational subjects are facts of the report.
Five unrelated organizations — a search giant, a global bank, a vector-database company, a national digital directorate, a city government — confirmed and fixed the same flaw in the same protocol. That sentence is the whole story. “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,” as the October research summary puts it; two CVEs have been published, and the findings stretch across five months of independent work. The most severe case rated 8 out of 10: “Google's MCP toolbox for databases initialized its HTTP client with no redirect policy and no validation of target IP addresses.”
1. The pattern has a name, and now a draft
The researcher behind the findings — cited here by work rather than name — generalized five months of cases into an IETF Internet-Draft, draft-mohiuddin-mcp-security-considerations-00, that gathers six vulnerability classes under one term: protocol pivoting. The attacker enters through the model-facing protocol and pivots into whatever the server can reach behind it. The relay is the heart of it, in the words Rapid7's vulnerability-intelligence director gave 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.”
That last sentence deserves to outlive the news cycle. It is the precise diagnosis of how multi-agent systems were assembled: not carelessly, but modularly — each protocol specified its own boundary, checked its own door, and left the connecting hallway as someone else's problem. Nobody's problem is everybody's problem at scale.
2. Why this is structural, not accidental
The root assumption, as the analysis records it, is that data crossing the protocol boundary is trusted because it came from inside the system. Five security teams in five unrelated institutions made the same call independently — which is how you know it is not a bug pattern but an architecture default. The scale is measurable: the MCPInspect study 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.” And the US federal finding is still open: “Five findings in US federal MCP servers are still open.”
Google's fix is the instructive one, because it shows where the boundary should have been all along: an allow-list of IP ranges plus block lists, rejecting an unsafe base URL at startup instead of on first request. Move the check earlier, bind it to configuration rather than to the mercy of a request — that is the difference between a patch and a boundary.
3. Design decides the blast radius — and then verification closes the hop
The defense guidance converges before anyone asks: the protocol's own security best practices and national agency guidance both say defense in depth, least privilege, and explicitly splitting read and write tools. The framing that sticks is blunt: “The blast radius is a design decision. Patching closes today's hole; tool design decides what the next hole costs you.” A read-only tool's worst case is a wrong answer; a write tool's worst case is a drained account. But the same analysis is honest about the ceiling of that approach: “A compromised upstream could still return false data, and no server-side design fixes that — only out-of-band verification does.”
Out-of-band verification is exactly where our two protocols live. RTTP(rttp://) gives the hallway a naming layer that is derived rather than registered, so a delegated task says who it came from as arithmetic, not as a lookup the upstream controls. IQA(iqa://) makes each hop carry a signed statement with a freshness lease, verifiable offline by the downstream agent — trust does not propagate across a hop; it gets re-established at each one, or the hop fails closed. We are not pretending attestation stops a pivot: a compromised agent can still sign things. What it changes is the economics — every hop leaves evidence a third party can check later, and the hallway stops being the one place in the building where nobody records anything.
Five organizations patched. The draft names the pattern. The hallway is still unlit — but for the first time it has an address, and addresses can be audited.