MCP Servers Are a Supply Chain Risk: 200,000 Exposed Instances

One design decision inside the official Model Context Protocol SDKs put an estimated 200,000 instances at risk, across a package ecosystem with more than 150 million downloads. OX Security disclosed it in April 2026. Anthropic confirmed the behaviour was intended and declined to change the protocol. MCP security is now a supply chain problem, and most teams connect third-party servers with no review at all.

What connecting an MCP server actually grants

The Model Context Protocol is the interface layer that lets an AI agent discover and call external tools. It solved a genuine problem, and it solved it well enough that the ecosystem standardised on it in under two years. The commercial logic behind that adoption is covered in the piece on how MCP became the agent interoperability standard.

The security question is separate, and it is narrower than it looks. When you add a connector, you are not subscribing to an API. You are adding a process that your agent will call on its own initiative, with your credentials, based on a description that the server itself wrote.

That last clause is the whole risk. The agent decides which tool to use by reading tool metadata supplied by the server. The server controls that text. Nobody on your side reviews it before the model acts on it.

Execution, not just data access

Most third-party risk reviews assume the vendor receives data. MCP inverts part of that. A local MCP server is a binary that runs on the same machine as the client, and the protocol's own documentation is direct about what follows.

The specification tells client implementers to warn users that MCP servers run with the same privileges as the client, and to show the exact command that will execute before connecting one. It lists arbitrary code execution, data exfiltration and irrecoverable data loss as consequences of an untrusted local server.

My reading of that page is that it is unusually honest for a protocol document. It names the failure modes plainly. What it cannot do is make anyone read it before running an install command from a README.

The flaw that made this a supply chain problem

On 15 April 2026, OX Security published research it titled The Mother of All AI Supply Chains. The finding was not a bug in one product. It was a behaviour present in Anthropic's official SDKs across Python, TypeScript, Java and Rust.

The scope OX reported: more than 150 million package downloads in the affected supply chain, over 7,000 publicly accessible servers, and up to 200,000 vulnerable instances in total. The disclosure produced 10 CVEs, 9 of them rated critical. The firm says it executed commands on six live production platforms and conducted more than 30 responsible disclosures.

What the STDIO transport does with a command

MCP clients start local servers by running a command. The STDIO transport passes the configured command and its parameters to the host system. A command that never initialises a valid MCP server still runs.

That means any surface which can influence a client's server configuration can run code on the host. OX described four routes into that surface, including unauthenticated interface injection and distribution through a marketplace. It also reported that a harmless trial payload was accepted by 9 of the 11 MCP registries it tested.

OX reports that Anthropic confirmed the behaviour is by design, described the STDIO execution model as a secure default, and treated sanitisation as the developer's responsibility. Anthropic raised no objection to publication. Read on its own terms that position is defensible, because a transport that runs a command is doing exactly what a transport that runs a command should do.

I still think it is the wrong call at ecosystem scale. Delegating sanitisation to thousands of downstream implementers is a bet that every one of them reads the specification, and the CVE record from the past year says they did not. The protocol's own security page is now longer and more detailed than most enterprise integration standards, which tells you where the burden landed.

Tool poisoning, measured against live servers

Tool poisoning is the attack where malicious instructions sit inside a tool's own metadata. Nothing executes. The agent simply reads the description and follows it.

Until 2025 this was demonstrated case by case. The MCPTox benchmark made it measurable. The researchers built the test set on 45 live, real-world MCP servers and 353 authentic tools, generating 1,312 malicious cases across 10 risk categories, then ran 20 prominent agents against them.

The headline result is an attack success rate of 72.8% for the worst-performing agent. The refusal figure matters more. Across every model tested, the highest refusal rate belonged to Claude-3.7-Sonnet, and it was under 3%.

Why the more capable models did worse

The paper's finding here is counterintuitive and worth stating precisely. More capable models were often more susceptible, because the attack exploits their instruction-following ability rather than defeating it.

That breaks the usual procurement instinct. Buying a better model is not a mitigation for this class of attack, and may make it worse. The authors are explicit that existing safety alignment is ineffective here, because the malicious action uses legitimate tools for unauthorised operations.

So refusal is not a control you can plan around. If your agent design assumes the model will decline an improper instruction embedded in tool metadata, the measured refusal rate says it will decline roughly 3 times in 100. Runtime observation is the layer that has to catch this instead, which is the subject of monitoring agent behaviour once it reaches production.

The first malicious MCP server found in the wild

In September 2025 a package called postmark-mcp appeared on npm. It was a near-exact copy of a legitimate MCP library, published by an account with no connection to the company whose name it carried.

Postmark's own statement is unambiguous. The company had not published an MCP server on npm before the incident, and it did not develop, authorise or have any involvement with the package. Its advice to anyone who installed it was to remove it, review email logs, and rotate any credential that may have passed through email during the exposure window.

Fifteen versions of trust, then one line of code

The attacker published versions 1.0.0 through 1.0.15 as working software. Version 1.0.16 added a single line that blind-copied every outgoing message to an address the attacker controlled.

That pattern defeats the review most teams actually run. A one-time check at install passes. The package was legitimate at install. The compromise arrives in an update that nobody re-reviews, and email is exactly the channel that carries password resets, invoices and API keys.

This is what makes MCP different from a normal npm dependency in practice rather than in theory. A poisoned utility library needs to find a path to something valuable. A poisoned connector is already holding the credential and already sitting inside the agent's tool list.

Rows one and three are incidents. Rows two, four, five and six are research and guidance. Only one row in this table describes confirmed harm to real users, which is worth holding on to when reading the rest.

Adoption has outpaced the vetting practice

The NSA's Artificial Intelligence Security Center published security design considerations for MCP on 20 May 2026. The framing in that release is the useful part for a buyer.

The agency states that agentic AI systems featuring MCP introduce novel and systemic risks including dynamic tool invocation, implicit trust relationships and context sharing. It then adds the line that should shape your process: these are not isolated problems that can be patched at the interface or endpoint level.

The Center for Internet Security reached the same conclusion from a different direction. Its MCP Companion Guide, published 20 April 2026, maps CIS Critical Security Controls onto MCP systems, on the basis that MCP expands the identity, access control, logging and application security surfaces at once.

The registry verifies ownership, not safety

It is tempting to assume a registry listing is a signal. It is worth knowing exactly what the official registry checks. It validates namespace ownership at publish time, so a server published under a GitHub-derived namespace proves the publisher controls that account.

That is real and it is useful. It is also not a security review. The registry documentation describes ownership verification through OAuth, DNS and HTTP methods, and carries a preview-status caveat. Nothing in it claims to inspect what a server does once it runs.

Namespace ownership would not have stopped postmark-mcp, because the attacker owned the npm account they published under. Typosquatting defeats provenance checks that only ask whether the publisher controls the name they chose. The identity side of this problem is covered separately in the piece on machine identity and non-human access.

A connector evaluation checklist you can run in an hour

Here is the practical part. Four gates, in order, each one cheap enough that a delivery lead can run it without a security team. A connector that fails any gate does not get added until the gap is closed.

The order matters because the gates get more expensive as you descend. Provenance takes five minutes and eliminates most candidates. Runtime containment takes a day and is the one people skip.

Gate 4 is the one that maps directly to the only confirmed in-the-wild incident. If you run only one of these four, run that one.

Two additions are worth making explicit. Diff the tool descriptions, not just the code, because tool poisoning lives in metadata and a description change is a smaller diff than most reviewers expect. And treat a connector that requests every available scope as a fail on principle, since the protocol's own guidance now argues for minimal initial scopes with step-up elevation.

Run the same discipline you would apply to any production dependency. The tests that separate a working demonstration from a deployable system are set out in the production readiness checks for AI pilots, and connector review belongs in that same gate rather than in a separate security backlog.

Where this argument is weakest

This section is mandatory here and it is the part I would read first if someone sent me this post.

The counts are estimates, not a census

The 200,000 figure is a blast radius calculation by a security vendor, not an observed count of compromised systems. OX reported 7,000-plus publicly accessible servers, which is a measurable population, and extrapolated the larger number from SDK download volumes.

Nobody has published a confirmed count of MCP servers compromised in the wild. The honest version of the headline is that a very large number of instances contained the behaviour, and an unknown and probably small number were attacked through it.

Most of this is ordinary supply chain risk with a new name

Typosquatting, malicious updates and over-scoped credentials predate MCP by a decade. A team with a working software supply chain practice already has most of the answer, and the four gates above are a restatement of controls that exist elsewhere.

What is genuinely new is narrower than the coverage suggests. It is the metadata channel, where a server writes text that the agent treats as instruction, and the autonomy that lets the agent act on it without a human in the loop. Everything else on the list is a familiar problem arriving through a new door.

A lot of the evidence comes from firms selling the fix

The scanning statistics circulating on MCP security come overwhelmingly from vendors with a scanning product. The percentages get restated across dozens of posts until they read like consensus, and they usually trace back to one unreplicated scan.

I have deliberately used the peer-reviewed benchmark, the affected company's own statement, the protocol specification and the government guidance as the load-bearing sources here. Where I have cited vendor research, it is because that vendor did the disclosure itself, and I have said so in the tooltip. Treat any MCP security percentage without a named sample and method as marketing.

What to do when a connector fails a gate

A fail is not automatically a rejection. It is a decision about who carries the risk, and the useful move is to name that person before the connector is added.

Three responses cover most cases. Wrap the server behind your own proxy that enforces scopes and logs calls, which converts a gate 2 or gate 3 failure into an engineering task. Replace the connector with a first-party implementation, which is worth it when the tool touches money, customer data or production infrastructure. Or accept the risk explicitly, with a named owner, a review date and a revocation path already tested.

What does not work is the fourth option, which is what most teams currently do. Someone adds it, it works, and it stays. That is the same shape as the unsanctioned tool problem quantified in the breakdown of what shadow AI costs when it breaches, and the fix is the same: inventory first, then policy.

Frequently asked questions

Where to start this week

First, produce the inventory. List every MCP server connected to any agent your team runs, including the ones on individual laptops, and write the credential each one holds next to it. Most teams discover the list is longer than they expected and that nobody owns half of it.

Second, pick the connector on that list with the widest credential and run gate 4 against it alone. Find out who would notice if it published a new version tomorrow, and how long revoking its token would actually take. If the answer to either question is nobody or unknown, you have found the work.

Related reading