MCP Supply Chain Security: How Malicious MCP Servers Are Infiltrating Enterprise AI Environments

TL;DR

• MCP servers are dependencies and like any dependency, they can be poisoned.
• Attackers are already typosquatting registries, backdooring npm packages, and pushing malicious updates to servers you already approved.
• The MCP ecosystem has no package security standard, no signing requirement, and no vetting baseline.
• Your defense: allowlist, pin versions, sandbox at runtime, and treat every MCP server like untrusted third-party code until proven otherwise.

AI Agents Have a Supply Chain Problem Nobody’s Solving

Every enterprise deploying AI agents is building on a foundation of third-party MCP servers they don’t control, can’t verify, and barely track. The security conversation keeps focusing on the model – prompt injection, jailbreaks, hallucinations. That’s the wrong place to look.

We’ve covered why that framing falls short elsewhere too – see System Prompts Are Not Security Boundaries. Business Logic Graphs Are. for why the model layer was never where this risk actually lives. 

The real exposure is the toolchain. MCP servers are the connective tissue between your AI agents and your actual systems – email, code repositories, databases, shell access. Every server your agent calls is a dependency. And like any dependency, it can be backdoored, typosquatted, or quietly updated to do something it wasn’t doing when you approved it.

Unlike npm or PyPI, the MCP ecosystem has no package signing requirement, no vetting baseline, no security standard of any kind. OX Security found that a single architectural flaw in Anthropic’s MCP SDK touched 150M+ downloads across the ecosystem. Trend Micro found 492 MCP servers sitting on the public internet with no authentication whatsoever.

The threat model isn’t a jailbroken model. It’s a legitimate agent, operating exactly as designed, faithfully executing instructions from a server you thought you could trust.

What the MCP Supply Chain Actually Looks Like

Most teams think of an MCP server as a tool they installed. The actual structure is a layered dependency chain, and every layer is a potential point of compromise.

The chain runs: registries and marketplaces, where developers discover and publish servers, to third-party publishers, to the MCP servers themselves, to the AI agents consuming them, to the enterprise systems those agents touch. Each link in that chain is a trust assumption. Agents don’t verify; they execute.

This is the npm problem, but with higher stakes. An npm package can corrupt a build pipeline. A malicious MCP server can silently exfiltrate credentials, forward emails, or execute arbitrary commands on production infrastructure – all while the agent reports back normally.

The registry layer is already compromised. OX Security tested 11 MCP registries with controlled malicious entries. Nine out of eleven accepted them. The discovery layer – where your developers find and install MCP servers – cannot be treated as a trusted source.

Most organisations don’t have a complete picture of which MCP servers their agents are actually calling. Shadow MCP – servers running in developer environments, CI pipelines, or agent configurations that never went through any formal review – is the baseline condition, not the exception.

Documented Attack: Kaspersky – Weaponizing Tool Descriptions

In September 2025, Kaspersky’s Global Emergency Response Team documented how MCP could be weaponized as a supply chain attack vector through a technique that requires no exploit, no vulnerability in the traditional sense – just an agent doing exactly what it was designed to do.

The attack targets tool descriptions. When an MCP server registers its tools with an agent, it provides descriptions of what those tools do. The agent reads those descriptions to understand how and when to use them. Attackers embed malicious directives inside those descriptions using XML-like tags – <IMPORTANT> blocks containing instructions that look, to the model, indistinguishable from legitimate documentation.

The model follows them. It has no mechanism to distinguish a tool description from an injected command. That’s not a bug waiting to be patched; it’s an architectural trust assumption baked into how the protocol works.

What gets exfiltrated through this vector: SSH keys, MCP configuration files containing credentials, full conversation histories. The agent doesn’t alert, doesn’t error, doesn’t behave anomalously. It just does what the description told it to do.

The implication is significant: you don’t need to compromise the model or find a vulnerability in the agent framework. You compromise what the model trusts. If you control the tool description, you control the agent’s behaviour.

Documented Attack: OX Security STDIO RCE – When the Protocol Is the Vulnerability

In April 2026, OX Security disclosed an architectural remote code execution vulnerability in Anthropic’s MCP SDK (we have mentioned this discovery multiple times above). Because the entire ecosystem builds on that SDK, the flaw propagated outward to every framework and implementation that inherited it.

CVEs were assigned across LangFlow, LiteLLM, Agent Zero, GPT Researcher, Fay, and LangBot. The vulnerability class: arbitrary command execution – meaning an attacker could run commands directly on any system hosting a vulnerable MCP implementation, with access to internal databases, API keys, and stored conversation data.

The researchers identified four distinct exploitation families. One of them requires zero user interaction: a prompt injection delivered through Windsurf or Cursor IDEs that executes silently in the developer’s environment. No clicks, no downloads, no social engineering.

Anthropic’s response to the disclosure was to decline patching, characterising the behaviour as “expected”. That position is worth sitting with. The protocol assumes trust at the foundation. When that assumption is the vulnerability, the vendor calling it expected behaviour means the entire ecosystem is operating on a foundation that will not be structurally fixed at the protocol level. Defence has to happen at the implementation layer – which is your problem, not Anthropic’s.

Attack Pattern 1 – Typosquatting: One Character, Full Compromise

Agents don’t make typos. Developers configuring them do. That’s the entire attack surface.

An attacker publishes an MCP server with a name one character off from a legitimate, widely-used server. A developer makes a single mistake at configuration time – a transposed letter, a missing hyphen, incorrect capitalisation. From that point forward, the agent faithfully routes every tool call, every credential, every data payload through the attacker’s server. No errors. No alerts. Normal operation, from the agent’s perspective.

UpGuard research found that for every legitimate MCP server, up to 15 lookalikes exist in the wild. That ratio reflects deliberate, scaled effort – attackers are systematically targeting the registry layer because it’s the easiest point of entry. For context on how hostile these lookalikes are: across major brand domains broadly, a lot of lookalike domains are actively malicious – running phishing infrastructure, dropping malware, or harvesting credentials.

The insidious part isn’t the initial compromise. It’s the duration. Because the agent operates normally and returns plausible results, there’s no failure signal to investigate. Exfiltration can run for weeks before anyone thinks to audit which server a particular agent is actually talking to.

Attack Pattern 2 – Backdoored Dependencies: The Long Game

In October 2025, a package called postmark-mcp appeared on npm, impersonating the legitimate Postmark email service. It published 15 clean, functional versions. It built a download history. It looked like a real, maintained package.

Version 1.0.16 added one line of code.

That line silently BCC’d every outbound email sent through the server to an attacker-controlled address. No crashes. No performance degradation. No anomalies in logs. Every email your agent sent – recipient addresses, subject lines, body content – forwarded in JSON payloads to phan@giftshop.club. The package ran for 8 days before researchers caught it, across roughly 1,600 installations.

That’s the template: patience, legitimacy-building, then a minimal surgical payload designed to avoid detection.

The same attack class at larger scale: CVE-2025-6514, a command injection vulnerability in mcp-remote, rated CVSS 9.6. It affected every version from 0.0.5 to 0.1.15 – patched only in 0.1.16 released June 2025. By disclosure, 437,000+ users were running vulnerable versions.

The lesson from both cases is the same. Trusting a package because it was clean last month is not a security posture. Version pinning, dependency auditing, and automated scanning aren’t hygiene niceties. They’re the controls that determine whether you catch this in hours or weeks.

Attack Pattern 3 – Rug Pulls: When Approved Servers Go Rogue

The most dangerous assumption in MCP security is that a server you vetted once stays safe. Rug pull attacks are built on exactly that gap.

The mechanic: a server passes your initial review. It behaves as documented. Your team approves it, agents start using it, and it earns a position of trusted dependency. Then – after consent is established, after the approval process is behind you – the server’s behaviour changes. A malicious update alters what the tool actually does. No re-consent is triggered. No alert fires. The agent keeps calling it with the same trust level it had on day one.

The Smithery.ai breach in October 2025 showed what this looks like at infrastructure scale. A path traversal vulnerability in the platform exposed builder credentials, Docker configurations, and Fly.io API tokens. An attacker confirmed root access via the id command and demonstrated the ability to sniff live network traffic. The blast radius: 3,000+ deployed applications compromised through a single platform vulnerability.

That’s not an edge case. Across a review of 2,614 MCP implementations, 82% were flagged for path traversal risk. Smithery was representative, not exceptional.

The governance gap this exposes is precise: approval at install time is not a security control. It’s a snapshot. Continuous verification – monitoring server behaviour, tracking updates, alerting on configuration changes – is what actually closes this attack surface.

Defenses: A Tiered Control Model

Defense here has to operate across three distinct moments: before a server is installed, while it’s running, and at the authentication layer. Securing one tier while leaving the others open is what attackers rely on.

Before install – supply chain integrity: Maintain a manifest-based allowlist. Nothing runs unless it’s explicitly approved. Pin versions or commit hashes and block automatic updates – the postmark-mcp attack worked because version 1.0.16 was a routine update, indistinguishable from the 15 that preceded it. Require cryptographic signature verification before installation. Generate SBOMs and run dependency analysis as part of the vetting pipeline, not as an afterthought.

At runtime – execution controls: Run MCP servers in containerised sandboxes with filesystem access scoped to only what the task requires. Validate the full argument list on every call – not just the base executable, but every flag. Explicitly reject shell-execution flags like -c and –eval. Sanitise inputs: strip control characters, enforce type validation, reject payloads exceeding size limits. Monitor outbound connections continuously – unexpected external calls are your earliest signal that something has changed.

Authentication layer: Replace static secrets. With a lot of MCP implementations using long-lived credentials that can’t easily rotate, this is the most widespread and correctable exposure in the ecosystem. OAuth 2.1 with PKCE, short-lived tokens, and narrowly scoped permissions is the standard. Enforce TLS/mTLS on all server connections. Default to least privilege – scope permissions to the minimum the specific task requires, not the maximum the server supports.

For a closer look at applying this specifically to agent tool chains, see MCP Access Control: How to Enforce Least Privilege Across AI Agent Tool Chains.

MCP Governance: Inventory, Registry, and Continuous Oversight

Controls without visibility are incomplete. An allowlist you can’t audit, a registry you don’t maintain, runtime monitoring with no one reviewing the alerts – these are theatre. Governance is what operationalises the defenses above.

1. Start with discovery. Catalog every MCP server currently in use – source code repositories, CI/CD pipelines, developer machines, agent deployment images. Shadow MCP is the most dangerous gap most organisations have right now: servers running in developer environments or agent configurations that never went through any formal review, with full access to production systems.
   This blind spot mirrors a problem we’ve written about in traditional API environments too – see Shadow and Zombie APIs: How to Improve Your API Security. 
2. Build a central authoritative registry. A single source of truth for approved servers, pinned versions, and permitted configurations. Every agent deployment references the registry. Anything not in it doesn’t run.
3. Formalize the vetting pipeline before servers reach the registry. Automated scanning for known vulnerabilities, secrets detection, dependency analysis – followed by manual security review for anything with broad system access. Generate SBOMs so you know exactly what each server is built on.
4. Enforce policy-as-code. RBAC mappings, logging requirements, and data-handling constraints should be defined at the repository level and applied consistently; not left to individual teams to interpret and implement differently across every agent project.
5. Monitor continuously. Real-time alerts on new server releases, authorization failures, and security advisories. Quarterly reviews to remove stale or unused registry entries and verify that what’s approved in the registry matches what’s actually deployed. Any drift between the two is an investigation trigger.
6. Log everything. Every tool execution should capture the tool name, server identity, description hash, argument digest, and response size. You cannot investigate what you didn’t record; and when a compromise surfaces, this data is the difference between a two-hour incident response and a two-week forensic exercise.

The MCP ecosystem is moving fast and governing slowly. Attackers have already adjusted. The organisations that treat MCP servers the way mature security teams treat any third-party dependency – with inventory, vetting, pinning, monitoring, and continuous review – are the ones that won’t be reconstructing an incident six months from now.

Frequently Asked Questions