MCP Supply Chain Campaign Anatomy

MCP (Model Context Protocol) is the wiring that lets an AI model reach outside its own head: discover tools, call APIs, read files, kick off workflows on whatever system happens to be connected. When a supply chain attack targets that wiring, it doesn't look like a single exploit. It looks like a staged operation, with an entry phase, a persistence phase, an execution phase, a lateral movement phase, and an exfiltration phase, each one setting up the next. Understanding that full sequence is the only way to catch it before the last stage, because by the time data actually leaves the building, four earlier chances to stop it have already passed.

The protocol itself runs on JSON-RPC 2.0, and it's had a fast few years. SDK downloads run about 97 million a month, more than 10,000 public servers exist, and Fortune 500 companies run MCP in production. Every major AI client speaks it now: ChatGPT, Claude, parts of Gemini, Microsoft Copilot, VS Code, Cursor, Replit. Forrester expects 30% of enterprise app vendors to ship their own MCP servers in 2026. That's a lot of surface area opening up while the defensive tooling still plays catch-up, and a single bad server can reach an enormous number of agents at once, because the client side of the ecosystem is basically universal.

Structural differences between MCP supply chain campaigns and conventional software supply chain attacks

A normal software supply chain attack targets an artifact. A tampered binary, a poisoned dependency, something you can catch at build time or at deploy time with a hash check or a scanner.

MCP attacks can occur without touching a binary. The attack surface is semantic: tool descriptions, parameter schemas, the actual content that comes back in a response. An AI agent treats all of that as trusted operational context, the same way it treats its own instructions. Poison the description, and you've poisoned the reasoning.

The chain is also multi-hop by design. A compromised or malicious server feeds a poisoned tool call, the agent reasons over that poisoned input, and the agent takes a downstream action based on what it now believes to be true. Each hop buys the attacker distance and deniability from the original compromise. And at no point in that chain does the current MCP spec offer a native way to catch a tool-description injection. Nothing flags it. Nothing blocks it. It just runs.

Stage 1: How attackers get a malicious MCP server in front of an agent

Three routes get a bad server in front of an agent, and each one fits a different kind of attacker.

The first is registry poisoning: publishing a server dressed up as something legitimate inside a public registry. Of six notable MCP security incidents tracked in 2026, three involved malicious servers sitting openly in public registries, not hidden, just unnoticed.

The second is patient. The SmartLoader operation, documented by Straiker STAR Labs in February 2026, built a fake developer ecosystem complete with the trust signals that come from looking established, before it ever deployed a payload. That's a meaningful data point: sophisticated operators are willing to invest significant time building legitimacy before cashing it in.

The third is the one with the widest blast radius, because it doesn't touch a single server, it touches the SDK layer everyone builds on. OX Security's research, titled "Mother of All AI Supply Chains," found a command execution vulnerability in Anthropic's official MCP SDKs across Python, TypeScript, Java, and Rust. The estimate: roughly 200,000 vulnerable instances, sitting inside a supply chain with more than 150 million package downloads behind it.

A design detail in the STDIO transport makes all of this worse. STDIO passes parameters straight to the OS shell without sanitizing them first. So anyone who can influence an MCP config file, whether through a compromised repo, a malicious registry listing, or plain social engineering, can get arbitrary code execution on the host machine. No exotic exploit required, just a config file nobody double-checked.

Lookalike servers add one more wrinkle. Research has found substantial numbers of lookalike servers for official MCP servers. It's typosquatting, but it's happening at the MCP registry layer instead of npm. The usual instincts developers have built up around package names don't fully transfer here.

What makes all of this hard to catch at the door is that a server that passed a clean audit last week can look completely different by the time an agent actually connects to it today. That sets up the next problem.

Stage 2: Establishing persistence through rug pulls and shadow infrastructure

MCP has no cryptographic content-addressing and no version pinning for tool descriptions. A server audited at one point in time can present entirely different behavior later, and there's no built-in way to notice the switch. That's the rug pull, and it's a semantic-layer attack by design, not a bug that slipped through.

CVE-2025-54136, disclosed in August 2025 with a CVSS score of 7.2, confirmed in a real production case that tool-definition approval in production AI development environments doesn't survive later server-side changes to that same tool. CVE-2025-54136, disclosed in August 2025 with a CVSS score of 7.2, confirmed that tool-definition approval in production AI development environments doesn't survive later server-side changes to that same tool. Approve it once, and the server can quietly change what "it" does afterward. That's a CVE-confirmed instance of the rug-pull pattern, not a hypothetical one.

Researchers at Cisco (Bhatt, Narajala, and Habler) formalized rug pulls and tool squatting as primary threat classes for MCP, and proposed fixes: cryptographic signing of tool definitions, immutable versioning. Sound fixes. Neither one is mandated by the current spec.

Shadow MCP servers make persistence even easier to pull off. A developer stands up an unregistered server to unblock a demo, a team wires an agent to whatever endpoint happens to be handy, and now there's infrastructure running that nobody governs, nobody patches, and nobody can revoke, because nobody officially knows it exists.

Stage 3: Execution, how tool poisoning and prompt injection turn trust into action

Tool poisoning means adversarial instructions get embedded directly into tool descriptions, parameter schemas, or response content. The agent reads that content as trusted operational context and acts on it, without ever showing it to the human on the other end.

That invisibility is the whole mechanism. Hidden instructions inside a tool description are visible to the AI model but never surface in the user interface. Simon Willison documented this in April 2025 as a prompt injection risk baked into MCP's architecture itself.

The numbers on this are stark. When AI agents auto-approve tool calls without validating them first, which is the default setting in most MCP deployments, attack success rates run above 84%, the direct cost of shipping "approve everything" as the default behavior. That's the direct cost of shipping "approve everything" as the default behavior.

Cross-server tool shadowing is the more unsettling variant. Invariant Labs demonstrated, in responsible disclosure, that a single malicious server can weaponize an adjacent, fully trusted server by injecting instructions that redirect the agent's tool calls elsewhere. The agent believes it's calling the trusted server. It's actually executing logic the attacker controls. From the outside, and from the agent's own perspective, nothing looks wrong.

Stage 4: Lateral movement across MCP-connected systems

A compromised MCP server rarely sits in isolation. It's typically wired into sensitive databases, internal APIs, file systems, enterprise SaaS tools, sometimes all four at once. Compromise that one server, and it acts as a pre-authenticated pivot point, skipping past authentication steps that would otherwise require a separate break-in for each system.

Overbroad permissions make the pivot possible. Agents and tools routinely get handed more access than the task in front of them actually needs. Breach one overprivileged identity, and it becomes a launchpad into everything connected to it. Minimal-privilege enforcement is the one structural control that actually caps how far the damage can spread.

Non-human identity sprawl makes the problem bigger than any single server. AI agents, service accounts, API keys, and OAuth tokens now outnumber human identities by more than 90 to 1 in many organizations, and most of those identities have no governance framework attached. No predictable lifecycle. No rotation schedule. They just sit there, valid indefinitely, until someone remembers to revoke them.

Secrets sprawl feeds the same fire. Leaked credentials and API keys sitting inside MCP-related configuration files represent potential lateral movement credentials, each one waiting to be discovered and abused.

Stage 5: Exfiltration, how MCP campaigns extract data while appearing to do normal work

The postmark-mcp incident is the case worth knowing in detail, because it's the first confirmed malicious MCP server found in the wild, and it's quiet in a way that matters. It didn't run a dramatic payload. It silently added a BCC recipient to every email an AI agent sent through the server, routing copies of those emails to an address the attacker controlled. It was designed so everything appeared normal.

It scaled, too. The exposure hit more than 437,000 environments. A quiet exfiltration pattern scales just as well as a loud one, maybe better, because loud patterns get noticed, and that number is the lesson.

The reason this is so hard to catch structurally: the agent still completes its actual task. The email gets sent. No error fires. The BCC, the malicious part, is invisible to the person who asked for the email. And most DLP tooling was never built to look inside MCP tool-call arguments, so it isn't positioned to catch this even in principle.

Context leakage is the quieter cousin of this problem. Sensitive data passed to one tool can become visible to others in the same session without any explicit exfiltration command being issued, a side effect of how multi-tool workflows are wired.

Coverage gaps in the current spec

The spec isn't empty on security. OAuth 2.1 with PKCE is the authentication standard. Enterprise-Managed Authorization (EMA) reached stable status in 2026, giving organizations centralized identity-provider control. And the 2026-07-28 spec update deprecated dynamic client registration in favor of Client ID Metadata Documents, adding issuer validation along the way.

What the spec doesn't do is arguably the bigger story. Authorization is marked optional, not required. There's no native defense anywhere in the spec against tool poisoning, rug pulls, or cross-server tool shadowing. Those are the three attack classes covered above, and the spec is silent on all of them.

Security concerns appear directly in adoption data. Half of builders name security and access control as their number one challenge, and 38% say security concerns are actively holding back wider adoption. Only 8.5% of servers actually use OAuth, so the vast majority of deployments run without the one authentication mechanism the spec does formally support.

Some of that gap is just churn. The 2026-07-28 spec update made significant changes to client registration. MCP is moving fast, and that pace of architectural change probably explains a good chunk of the uneven compliance visible across real-world deployments. Standards that move this fast are hard to keep up with, and it shows.

Intercepting each stage of the campaign before it happens

The organizing principle is simple: intercept as early in the chain as possible. A control placed at Stage 1 stops an attack before it ever gets a foothold. The same control placed at Stage 5, after data has already left, is forensics.

At entry, that means treating registry listings the way a security team treats any third-party dependency: verify publishers, watch for lookalike naming, and don't let a config file get written by anyone outside a reviewed change process. The STDIO shell-injection risk is a solvable problem if input sanitization happens before, not after, a parameter reaches the OS shell.

At persistence, cryptographic signing and immutable versioning of tool definitions close the rug-pull window directly, even though neither is mandated by the spec yet. Nothing stops an organization from enforcing that internally, checking a tool's signature against what was approved at audit time, rather than trusting that nothing changed since.

At execution, the fix is uncomfortable but obvious: stop auto-approving tool calls. An 84% attack success rate under auto-approval is not a rounding error, for it's a default setting doing what a bad default does. Human review, or at minimum policy-based validation, on tool calls that touch sensitive systems closes most of that gap on its own.

At lateral movement, minimal-privilege enforcement and real governance over non-human identities (rotation schedules, defined lifecycles, actual ownership) shrink the blast radius even when a single server does get compromised. And at exfiltration, tooling that can actually inspect MCP tool-call arguments, not just the surrounding network traffic, is the only way to catch a quiet hidden-recipient-style redirect before it reaches half a million environments instead of zero.

None of these controls require rewriting the MCP spec. They require treating each stage of the chain as a distinct decision point, because a campaign built in five stages can be broken at any one of them, and the earlier that break happens, the cheaper it is.