MCP Supply Chain Attacks: Why Better Models Make It Worse

Manveer Chawla

SubscribeSign in

Smarter Models, Dumber Security<br>MCP is becoming the next supply-chain risk, and today’s defenses are watching the wrong part of the attack.

Manveer Chawla<br>Jun 16, 2026

Share

You install a well-starred MCP server for Figma design tokens. Ten thousand GitHub stars, 600,000-plus downloads. Your agent calls it to fetch a file. The fileKey parameter passes unsanitized straight into child_process.exec. An attacker who controls that file key, via a poisoned Figma link, a prompt injection upstream, or a malicious issue in a repo your agent is processing, gets shell execution on your machine. This is CVE-2025-53967. The server was a thin API wrapper built with trusted-input assumptions, deployed in an environment where input comes from an LLM that can be compromised.<br>MCP has become the most popular way to connect AI agents to external tools. The ecosystem grows fast: major registries list thousands of public servers, every major IDE ships with MCP support, and Cursor alone has over a million users with MCP enabled. But the security model sits where npm sat circa 2015: no package signing, no sandboxing, no runtime isolation between servers. Local stdio MCP servers commonly run with the invoking user’s OS privileges, the protocol does not mandate sandboxing, and the model cannot distinguish a tool’s documentation from a tool’s instructions.<br>Thanks for reading! Subscribe for free to receive new posts and support my work.

Subscribe

Better models will not fix this. The MCPTox benchmark, the first large-scale systematic test of tool poisoning, found that more capable models are more susceptible because the attack exploits superior instruction-following. The highest refusal rate across all models tested was under 3%. An empirical study of 1,899 MCP servers found 5.5% contain description patterns consistent with tool poisoning. The attack surface grows faster than the defenses.<br>The Figma CVE represents one class of MCP vulnerability: a server built with trusted-input assumptions that gets exploited at runtime. But the deeper structural problem cuts worse. A poisoned MCP server does not even need to be called to compromise your environment. Its description alone, sitting in the shared context window, can redirect every other tool.<br>TL;DR

A poisoned MCP tool compromises your environment without being called. Its description contaminates the shared context window, redirecting every connected tool.

Three attack phases exploit three broken assumptions. Description poisoning on install, rug pulls post-approval, and output injection at runtime each bypass a different trust boundary.

More capable models are more vulnerable, not less. MCPTox found the highest refusal rate across all models was under 3%. Better instruction-following means more reliable exploitation.

Pinning solves one phase out of three. Runtime authorization, lifecycle governance, and context isolation address the rest, but have not reached mainstream adoption.

Prerequisites : Familiarity with MCP basics, what a server is and how tools are registered. The MCP specification covers the fundamentals.<br>The npm Analogy, And Where It Breaks Down

Most backend engineers have lived through npm’s supply-chain arc. The story unfolded in three beats: left-pad in 2016, where accidental package removal broke thousands of builds and revealed how a single maintainer could disrupt the ecosystem. Then event-stream in 2018, where a social-engineering attack transferred maintainership of a popular package to an attacker who injected code targeting cryptocurrency wallets, a deliberate, targeted supply-chain compromise. Then ua-parser-js and colors.js in 2021 and 2022, where maintainer account compromises and intentional sabotage hit packages with tens of millions of weekly downloads. Each incident escalated in sophistication.<br>The npm ecosystem eventually developed real defenses. Package-lock files pinned dependency trees. npm audit surfaced known vulnerabilities. Sigstore provenance attestation, available since 2023, lets consumers verify that a package was built from a specific commit by a specific CI pipeline. Scoped registries, organizational namespaces, and publish access controls added governance layers. MCP has no protocol-mandated equivalent. No universal package signing, no required provenance verification, no standard runtime isolation.<br>But the structural difference between npm and MCP runs deeper than missing tooling. In npm, a poisoned package must be require()’d or imported to run its code. There is a concrete moment of execution. In MCP, a poisoned server’s tool description is injected into the LLM’s shared context window alongside every other connected server the moment it is installed. It contaminates the model’s behavior toward completely unrelated tools with zero invocation required.

Think of it as an npm package that silently rewrites the runtime behavior of every...