MCP supply chain attacks exploit the shared context window
Manveer Chawla's analysis of MCP security shows that poisoned tool descriptions can compromise an agent's entire environment without ever being invoked, and that more capable models are more reliably exploited — not less.
Score breakdown
The shared context window architecture means a single malicious MCP server description can redirect every other connected tool without being called, and the defenses that eventually hardened npm — signing, sandboxing, provenance — do not yet exist as MCP protocol requirements.
- 01CVE-2025-53967: a Figma MCP server with 600,000+ downloads passed `fileKey` unsanitized into `child_process.exec`, enabling shell execution.
- 02A poisoned MCP server's description contaminates the shared context window at install time — no invocation required to compromise connected tools.
- 03MCPTox, described as the first large-scale systematic tool-poisoning benchmark, found the highest refusal rate across all tested models was under 3%.
Manveer Chawla's post opens with CVE-2025-53967, a vulnerability in a Figma MCP server carrying over 10,000 GitHub stars and 600,000-plus downloads. The server passed the `fileKey` parameter unsanitized into `child_process.exec`, meaning an attacker who controls that file key — via a poisoned Figma link, prompt injection, or a malicious issue in a repo an agent is processing — achieves shell execution on the user's machine. The post frames this as one class of MCP vulnerability: a server built with trusted-input assumptions deployed in an environment where input originates from a potentially compromised LLM.
The deeper structural problem, the post argues, is the shared context window.
The deeper structural problem, the post argues, is the shared context window. Every connected MCP server feeds its tool descriptions, parameter schemas, and metadata into the same unpartitioned context the model reasons over. Unlike npm, where a poisoned package must be explicitly `require()`'d to execute, a poisoned MCP server's description is injected into the model's reasoning space at install time, with no invocation required. This means a malicious trivia game sitting alongside a database tool and a Slack integration can redirect the model's behavior toward all of them simultaneously. The post identifies three attack phases — description poisoning on install, rug pulls post-approval, and output injection at runtime — each bypassing a different trust boundary.
Critically, the post cites the MCPTox benchmark, described as the first large-scale systematic test of tool poisoning, which found that more capable models are *more* susceptible because the attack exploits superior instruction-following. An empirical study of 1,899 MCP servers found 5.5% contain description patterns consistent with tool poisoning. The post draws a parallel to npm's supply-chain arc — left-pad (2016), event-stream (2018), ua-parser-js and colors.js (2021–2022) — noting that npm eventually developed defenses like package-lock files, `npm audit`, and Sigstore provenance attestation, none of which have protocol-mandated equivalents in MCP today.
Key facts
- 01CVE-2025-53967: a Figma MCP server with 600,000+ downloads passed `fileKey` unsanitized into `child_process.exec`, enabling shell execution.
- 02A poisoned MCP server's description contaminates the shared context window at install time — no invocation required to compromise connected tools.
- 03MCPTox, described as the first large-scale systematic tool-poisoning benchmark, found the highest refusal rate across all tested models was under 3%.
- 04More capable models are more susceptible to tool poisoning because the attack exploits superior instruction-following.
- 05An empirical study of 1,899 MCP servers found 5.5% contain description patterns consistent with tool poisoning.
- 06MCP has no protocol-mandated package signing, provenance verification, or runtime isolation between servers.
- 07Local stdio MCP servers commonly run with the invoking user's full OS privileges.
Topics
Summary and scoring are generated automatically from the original article. We always link back to the publisher and never republish images or paywalled content. Last processed Jun 16, 2026 · 23:11 UTC. How this works →