MCP Supply Chain Poisoning: How Rogue Servers and Hallucinated Packages Compromise AI Toolchains
Nineteen typosquatted npm packages. A rogue MCP server silently injected into your coding assistant. Your AI reads your SSH keys and sends them to an attacker-controlled endpoint as part of its normal workflow. SANDWORM_MODE was not a proof of concept. It was a production campaign. And slopsquatting means the model itself is generating the attack vector.
11 min read
The New Attack Surface
Software supply chain attacks are not new. Typosquatting on npm, dependency confusion, and malicious packages have been documented threats for years. What changed in 2026 is the target: AI coding assistants and the Model Context Protocol infrastructure that connects them to real systems. The attack surface shifted from tricking developers into installing bad packages to tricking the tools developers trust to install packages for them.
Three developments converged in early 2026 to create a supply chain crisis specific to AI-assisted development. A worm-like npm campaign called SANDWORM_MODE weaponized typosquatting to inject rogue MCP servers into coding assistants. OX Security disclosed a systemic remote code execution flaw baked into every official MCP SDK. And researchers documented slopsquatting, a new attack class where adversaries register package names that LLMs reliably hallucinate. Together, these threats define a category that did not exist eighteen months ago.
This article is a companion to MCP Security: Risks Every Developer Should Know, which covers prompt injection and tool poisoning at the protocol level. Here, the focus is on the supply chain: how malicious code reaches your machine before you ever approve a tool call.
SANDWORM_MODE: The Campaign That Targeted AI Toolchains
On February 20, 2026, Socket's Threat Research Team disclosed a multi-stage npm supply chain attack operating under an internal flag called SANDWORM_MODE. Nineteen typosquatted packages, published under the aliases official334 and javaorg, impersonated popular developer utilities and AI coding tools. Three packages impersonated Claude Code directly. Others mimicked common npm utilities like supports-color. [1]
The campaign's technical sophistication set it apart from routine typosquatting. It operated in two deliberate phases. The first phase executed immediately on install: it harvested cryptocurrency keys, npm tokens, and environment variables. The second phase was deferred, designed to evade short-lived sandbox analysis. It deployed persistence mechanisms, propagation logic, and the component that made this campaign unprecedented: MCP server injection. [2]
The malware scanned for configuration files belonging to Claude Code, Claude Desktop, Cursor, VS Code Continue, and Windsurf. When it found one, it injected a rogue MCP server into the configuration. Once active, the server's system prompt used prompt injection to instruct the AI assistant to silently read and exfiltrate SSH keys, AWS credentials, npm tokens, and environment secrets through the tool interface. The AI performed the exfiltration as part of its normal workflow. The user never saw a separate process or network request.
CrowdStrike's subsequent analysis confirmed the campaign's intent to blend into trusted development activity. Rather than executing overtly malicious behavior that might trigger security alerts, the malware abused actions that AI coding assistants already perform: reading files, accessing environment variables, making network requests. The worm then propagated by using stolen npm and GitHub credentials to inject dependencies into other repositories and trigger pull request workflows in GitHub Actions. [3]
The MCP SDK Flaw: Remote Code Execution by Design
Two months after SANDWORM_MODE, on April 15, 2026, OX Security published an advisory that reframed the MCP supply chain problem. The vulnerability they disclosed was not a coding error. It was an architectural design decision baked into Anthropic's official MCP SDKs across every supported programming language: Python, TypeScript, Java, and Rust. [4]
The STDIO transport, the most widely used mechanism for connecting MCP clients to local servers, processes incoming configuration by passing parameters directly to the host operating system's shell without input sanitization or validation. Any MCP server that accepts user-influenced input through this transport can be leveraged for arbitrary command execution on the host machine. This is not a bug to be patched. Anthropic characterized the behavior as intentional, meaning no vendor fix is forthcoming. [5]
The scale of exposure is staggering. OX Security estimated approximately 200,000 vulnerable MCP instances across a supply chain encompassing more than 150 million package downloads. The Cloud Security Alliance's subsequent analysis confirmed 7,000 publicly reachable servers, 14 CVEs already assigned, and more than 30 remote code execution issues affecting widely used products including LiteLLM, LangFlow, Windsurf, Cursor, Flowise, DocsGPT, and GPT Researcher. [5]
A CSA Labs scan of 1,899 MCP servers in May 2026 found a 5.5% tool poisoning rate. Zero percent of scanned servers included security documentation. The gap between adoption velocity and security maturity is not narrowing. It is widening. [5]
Slopsquatting: When the Model Is the Attack Vector
Typosquatting exploits human typing errors. Slopsquatting exploits machine hallucination. The term, coined in early 2025, describes a supply chain attack where adversaries register package names that large language models reliably hallucinate when generating code. The attacker does not need to guess what a developer might mistype. The attacker only needs to observe what the model consistently invents. [6]
The mechanism is straightforward. LLMs generate plausible-sounding but nonexistent package names with measurable frequency. Open-source models hallucinate packages at an average rate of 21.7%. Commercial models average 5.2%, with GPT-4 Turbo achieving the lowest measured rate at 3.59%. Even at that floor, the volume of AI-generated code in 2026 makes the absolute number of hallucinated package references enormous. [6]
Two cases illustrate the threat in practice.
The npm package unused-imports is one of the clearest documented cases. AI models hallucinate this name instead of the legitimate eslint-plugin-unused-imports. As of early 2026, a malicious package registered under that name was recording approximately 233 weekly downloads despite being security-held by npm. [7]
The package react-codeshift demonstrates a subtler pattern. Two real packages exist with similar names: jscodeshift and react-codemod. LLMs mash them together, inventing react-codeshift. A researcher registered the name in January 2026 and documented it propagating through 237 repositories via AI-generated agent skills. The downloads were not driven by human developers copying code. They were driven by autonomous agents executing their own generated outputs. [8]
Socket's research identified 127 hallucinated package names shared across Claude Sonnet, Claude Haiku, GPT, Gemini, and DeepSeek models, with 53 of those names still available for registration on PyPI and npm as of April 2026. The hallucinations are not random. They are deterministic enough to predict and weaponize. [8]
The Autonomous Agent Amplifier
Every supply chain attack described above is amplified by a single trend: autonomous coding agents that install packages, configure tools, and execute code without human review. When a developer reads AI-generated code and manually runs npm install, there is at least a moment where a hallucinated or typosquatted package name might be caught. When an agent runs the install command as part of a multi-step task, that moment disappears.
Research published in mid-2026 found that AI-agent skills carry a risk rate 2.3 times higher than IDE extensions. The first half of 2026 produced more than 2.6 times the supply chain campaign volume and 4.5 times the malicious package volume of the entire preceding year. The acceleration is directly correlated with agent adoption: more autonomous tooling means more automated installation of unvetted dependencies. [9]
The react-codeshift case is the proof of concept. Those 237 repositories were not infected by developers copying bad code from a chat window. They were infected by agents generating code, installing the hallucinated package, and committing the result. The agent was the distribution mechanism. This is slopsquatting's endgame scenario: the model hallucinates the name, the agent installs it, the malicious payload executes, and the compromised credentials propagate the infection further. No human is in the loop at any point.
The SANDWORM_MODE campaign demonstrated what this looks like in practice. Once a rogue MCP server was injected, the AI assistant itself became the exfiltration tool. The agent sandbox was not the agent's runtime environment. It was the agent's configuration file. And most coding assistants do not sandbox their configuration.
The Anatomy of an MCP Supply Chain Attack
Pulling these threads together, a modern MCP supply chain attack follows a recognizable pattern:
Entry — A malicious package reaches the developer's machine through typosquatting (SANDWORM_MODE), slopsquatting (LLM hallucination), or dependency confusion. The vector is a standard package registry: npm, PyPI, or a language-specific equivalent.
Injection — The payload modifies the configuration files of AI coding assistants, injecting a rogue MCP server definition. The configuration format is JSON. The modification is silent.
Weaponization — The rogue MCP server uses prompt injection to instruct the AI to read secrets from the local file system, environment variables, and credential stores. The AI complies because the instructions arrive through a trusted channel: its own tool configuration.
Exfiltration — Credentials are sent to attacker-controlled endpoints through the MCP server's own network requests or through the AI's existing tool calls. The traffic looks like normal development activity.
Propagation — Stolen npm tokens and GitHub credentials are used to inject dependencies into other repositories, publish new malicious packages, or trigger CI/CD workflows that spread the infection to downstream projects.
Each stage exploits a different trust boundary. The package registry trusts the publisher. The developer trusts the package. The AI assistant trusts its configuration. The CI pipeline trusts the committed code. The downstream project trusts the dependency. A single compromised package can cascade through all five.
Defenses That Actually Work
The supply chain attacks documented in 2026 share a common property: they succeed because the default configurations of both package registries and AI coding assistants assume trust. Effective defense requires replacing assumed trust with verified trust at every layer.
Package-Level Defenses
Lock and verify dependencies. Use lockfiles with integrity hashes. Run supply chain scanners like Socket, Snyk, or npm audit on every install. Do not auto-approve dependency updates in CI.
Validate AI-suggested packages before installing. When an AI coding assistant suggests a package name, verify it exists on the registry, check its download count, inspect its publisher history, and read its source. A package with zero downloads published yesterday is not the popular utility the model thinks it is.
Use private registries or scoped packages for internal code. Dependency confusion attacks exploit the gap between internal and public package names. Scoping eliminates that gap.
MCP Configuration Defenses
Monitor your MCP configuration files. The SANDWORM_MODE attack modified JSON configuration files on disk. File integrity monitoring on Claude Code, Cursor, and Windsurf configuration directories would have detected the injection immediately.
Audit installed MCP servers regularly. Know which MCP servers are configured in your environment. If a server appears that you did not install, treat it as a compromise indicator.
Pin MCP server versions. Just as you pin npm dependencies, pin the versions of MCP servers you use. An auto-updated MCP server is a supply chain attack waiting to happen.
Agent Workflow Defenses
Never let agents auto-install packages. Require human approval for any npm install, pip install, or equivalent command. This is the single most effective defense against slopsquatting.
Run agents in isolated environments. Agents should not have access to production credentials, SSH keys, or cloud tokens. Sandbox the runtime so that even a compromised agent cannot reach secrets worth stealing.
Separate development and production MCP configurations. Do not configure MCP servers with production database access in the same environment where you experiment with new tools or untrusted packages.
What Comes Next
The MCP supply chain crisis is not a single vulnerability to patch. It is a structural problem created by the intersection of three forces: package registries that assume publishers are benign, AI models that hallucinate package names at predictable rates, and autonomous agents that execute install commands without human review. Fixing any one of these forces helps. Fixing all three is what production safety requires.
The MCP specification is evolving. The protocol's authorization model is being hardened with each revision. But the STDIO transport vulnerability that OX Security disclosed is a design choice, not a bug, and architectural decisions propagate through ecosystems far more slowly than patches. Enterprises running MCP-enabled infrastructure must treat this as an active risk requiring immediate architectural review, strict access controls, and network segmentation of MCP endpoints. [4]
The developers who audit their MCP configurations, validate every package an AI suggests, and refuse to let agents auto-install dependencies are building the habits that will define secure AI-assisted development. The developers who trust the defaults are building the incident reports that everyone else will learn from.