The MCP Breach Timeline: What 10 Months of Vulnerabilities Teach Us

Algis Dumbris • 2026/03/20

The Timeline at a Glance

Between April and December 2025, the Model Context Protocol ecosystem experienced a concentrated wave of security incidents that collectively exposed every foundational assumption about agent-tool trust. AuthZed’s comprehensive breach timeline documents nine major incidents across ten months, each one exploiting a different facet of the same underlying problem: MCP was designed for capability, not containment.

The timeline reads like an escalation playbook:

• April 2025 — A malicious MCP server combined with a legitimate WhatsApp integration exfiltrated hundreds of WhatsApp messages to attacker-controlled numbers, bypassing every DLP tool in the chain. Classic tool poisoning.
• May 2025 — Malicious GitHub issues injected prompts that hijacked AI assistants, pulling private repository contents, project details, and financial data into public pull requests. Prompt injection through untrusted content.
• June 2025 — An Asana MCP server integration failed at cross-tenant isolation, potentially exposing one organization’s projects to another. Access control logic flaw. That same month, the Anthropic MCP Inspector — a developer tool — was found to allow unauthenticated remote code execution on localhost, exposing the entire filesystem, API keys, and environment secrets.
• July 2025 — CVE-2025-6514 hit the widely-used mcp-remote package (437,000 downloads). Malicious OAuth authorization endpoints passed unsanitized input to the system shell, enabling theft of API keys, cloud credentials, SSH keys, and Git repository contents.
• August 2025 — Anthropic’s own Filesystem MCP Server was found to have sandbox escape vulnerabilities via symlink bypass, allowing arbitrary filesystem access.
• September 2025 — A malicious Postmark MCP server appeared in the wild, silently BCC-ing every email to attacker infrastructure. A supply chain attack in its purest form.
• October 2025 — Two incidents closed out the timeline. Smithery, an MCP hosting platform, suffered a path traversal breach in its build configuration that leaked Docker credentials and compromised 3,000 apps. Separately, the Figma/Framelink MCP integration was found vulnerable to command injection via unsanitized user input in child_process.exec.

Nine incidents. Ten months. Every one of them maps to a pattern that security engineers have been warning about since the protocol launched. The question was never if these attacks would happen — it was how quickly the ecosystem would produce defenses.

Pattern 1: Tool Poisoning and the Quarantine Response

The WhatsApp exfiltration in April and the fake Postmark server in September share a root cause: the agent trusted tool descriptions and behaviors that had not been verified. In both cases, the MCP server presented a plausible interface while executing hidden logic — redirecting messages, BCC-ing emails — that the agent had no mechanism to detect.

The OWASP MCP Top 10 codifies this as MCP03: Tool Poisoning — adversaries compromise tools or alter their outputs by injecting malicious context to manipulate model behavior. Elastic Security Labs’ analysis goes further, identifying specific techniques: schema poisoning, tool shadowing (a malicious read_text_file masquerading as the legitimate one), and rug-pull redefinitions where tools silently alter their behavior after initial approval.

Tool poisoning exploits a structural gap in MCP: there is no standard verification step between “server presents tool descriptions” and “agent starts using tools.” The agent receives a tools/list response and immediately incorporates those tools into its planning.

MCPProxy’s quarantine system inserts exactly that missing step. When a new MCP server connects, its tool schemas are placed in quarantine — visible for inspection but unavailable for agent invocation. The operator reviews the tool names, descriptions, parameter schemas, and annotations before approving the server for production use:

mcpproxy upstream list          # see all servers and their status
mcpproxy upstream approve <id>  # move from quarantine to active

This is not a scan. It is a hard gate. No tool reaches the agent’s tool pool without explicit operator approval. The September Postmark incident — a server that looked legitimate but silently exfiltrated data — would have been caught during quarantine review, where the operator can inspect the actual tool behavior and compare it against expected functionality.

Pattern 2: Sandbox Escapes and Docker Isolation

The August 2025 Filesystem MCP Server vulnerability demonstrated that application-level sandboxing is insufficient. Anthropic’s own implementation attempted to restrict file access to declared directories, but symlink traversal bypassed those restrictions entirely, granting arbitrary filesystem access.

This is not surprising. Application-level path validation has a long history of failure — every web framework has dealt with directory traversal vulnerabilities. The problem is that the MCP server process runs with the full permissions of its host, and any logic flaw in the server code can escalate to those permissions.

MCPProxy’s Docker isolation moves the containment boundary from the application layer to the operating system layer. Each MCP server runs inside its own container with explicit resource limits, network policies, and filesystem mounts:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/data"],
      "docker": {
        "enabled": true,
        "image": "node:22-alpine",
        "volumes": ["/safe/path:/data:ro"],
        "network": "none"
      }
    }
  }
}

A symlink inside the container resolves within the container’s filesystem, not the host’s. The volumes declaration makes the containment boundary explicit and auditable — the server can access /data read-only and nothing else. Network isolation ("network": "none") prevents the server from phoning home even if compromised.

The Smithery breach in October reinforces this point from the hosting side. A path traversal in the build configuration leaked Docker credentials because the build process ran with access to the builder’s home directory. Container isolation with minimal volume mounts prevents this entire class of attack by ensuring the server never has access to credentials it does not need.

Pattern 3: Over-Privileged Access and BM25 Scoped Discovery

The Asana cross-tenant failure and the MCP Inspector RCE share a common theme: components with more access than they needed. The Asana integration could reach across tenant boundaries. The Inspector exposed the full filesystem to unauthenticated requests. In both cases, the blast radius of a single vulnerability extended far beyond the component’s intended scope.

OWASP MCP02: Privilege Escalation via Scope Creep describes this pattern precisely — loosely defined permissions expand over time, granting agents excessive capabilities. Unit 42’s research demonstrates the practical consequence: covert tool invocation, where compromised servers instruct the LLM to silently invoke other available tools for file operations and data exfiltration.

The key insight is that an agent can only misuse tools it can see. If an agent working on a text processing task has access to filesystem tools, database tools, and network tools, a single prompt injection can pivot across all of them. Reduce the visible tool set and you reduce the blast radius.

MCPProxy’s BM25 tool discovery does exactly this. When an agent connects to MCPProxy with 15 upstream servers exposing 200+ tools, the BM25 engine scores all tools against the current request context and presents only the top-K most relevant ones. A code review agent sees code analysis tools. A documentation agent sees content tools. Neither sees the other’s capabilities.

This is primarily a usability optimization — agents make better decisions from focused tool lists — but the security benefit is direct. The Unit 42 covert tool invocation attack requires the target tools to be visible in the agent’s context. BM25 scoping removes tools that are irrelevant to the current task, shrinking the attack surface proportionally.

Pattern 4: Supply Chain Attacks and Server Verification

The mcp-remote CVE in July (437,000 affected downloads) and the Smithery platform breach in October (3,000 compromised apps) are supply chain attacks — the server or its distribution channel was compromised before the operator ever saw it. OWASP MCP04: Software Supply Chain Attacks highlights this as one of the top risks: compromised open-source packages introduce execution-level backdoors.

Traditional package security measures — signed releases, dependency pinning, vulnerability scanning — apply here, but MCP adds a layer of complexity. An MCP server is not just a library; it is an active process that makes tool descriptions available to an AI agent. A compromised server can present benign descriptions during scanning and alter its behavior at runtime. Elastic’s research documented this as the “rug-pull” pattern: tools that pass initial review and later modify their schemas or behavior.

MCPProxy addresses supply chain risk through the combination of quarantine and Docker isolation. Quarantine prevents a newly installed server from reaching the agent until explicitly approved. Docker isolation limits what a compromised server can access even after approval. Together, they implement defense in depth — the supply chain attack must survive both the approval gate and the runtime containment to cause damage.

The mcpproxy upstream add workflow makes this explicit:

mcpproxy upstream add github-server    # server enters quarantine
mcpproxy upstream list                 # inspect tool schemas
mcpproxy upstream approve github-server # promote to active

Every server starts untrusted. Trust is granted through explicit operator action, not through package popularity or registry presence.

Pattern 5: Prompt Injection at Scale and Gateway-Level Interception

The May 2025 GitHub incident was prompt injection at its most damaging: malicious content in GitHub issues hijacked AI assistants into leaking private repository data. This was not an exotic attack. It was untrusted user content flowing through a tool response into the agent’s context, where it was interpreted as instructions.

Elastic’s analysis found that 43% of tested MCP implementations contained command injection flaws and 30% permitted unrestricted URL fetching. Practical DevSecOps research emphasizes that prompt injection is the most common MCP vulnerability, requiring rigorous input validation and sanitization before payloads reach the model.

The challenge with prompt injection is that it exploits the fundamental mechanism of LLM-based agents: they process text as instructions. No amount of application-level filtering can reliably distinguish legitimate tool output from injected instructions — the boundary between data and code does not exist in natural language.

This is where gateway-level architecture matters. MCPProxy sits between the agent and all upstream servers, which means it observes every tool request and every tool response. This positioning enables pattern detection, rate limiting, and anomaly flagging that individual MCP servers cannot implement for themselves. A server does not know what other servers the agent is talking to, what the broader request context looks like, or whether a sequence of tool calls represents normal behavior or an injection-driven pivot.

Gateway-level interception does not solve prompt injection — nothing does completely. But it changes the economics. Without a gateway, each MCP server is an independent attack surface with no shared context. With a gateway, defensive logic applies uniformly across all servers, and cross-server attack patterns become detectable.

The Meta-Lesson: Old Principles, New Surfaces

The most striking thing about AuthZed’s timeline is how familiar the vulnerabilities are. Tool poisoning is supply chain compromise applied to AI tool descriptions. Sandbox escapes are directory traversal applied to MCP server containment. Over-privileged access is least-privilege violations applied to agent capabilities. Prompt injection is code injection applied to natural language interfaces.

Every breach in the timeline maps to a security principle that predates AI by decades:

The MCP ecosystem spent ten months learning — through production incidents — that these principles apply to agent-tool interactions just as they apply to every other software boundary. The protocol itself provides capability. Security requires infrastructure that wraps that capability in containment, verification, and scoped access.

MCPProxy ships all five defense layers as a single binary. Quarantine gates untrusted servers. Docker isolation enforces OS-level containment. BM25 scoping reduces the visible attack surface. The upstream verification workflow addresses supply chain risk. And the gateway architecture provides the observation point for cross-server defense.

The breach timeline will continue. New attack vectors will emerge as MCP adoption grows and agents gain more capabilities. But the defensive principles are stable. They have been stable for forty years. The only question is whether the infrastructure enforcing them can keep pace with the protocol’s expansion.

MCPProxy is open source at github.com/smart-mcp-proxy/mcpproxy-go. Install and run with mcpproxy serve to add quarantine, Docker isolation, and BM25 tool scoping to any MCP deployment.