All posts
· 11 min read ·

19 typosquatted npm packages, one new attack surface: the AI agent's MCP configuration

Mini Shai-Hulud (May 12) compromised 160+ packages including TanStack, Mistral AI, and UiPath. SANDWORM_MODE shipped 19 typosquatted AI-coding packages. The April 4 MCP Connector Poisoning disclosure named the new payload: a rogue MCP server injected into the agent's IDE configuration. No agent-side exploit required — the trust model breaks at step 5.

Five days before this post, on May 12, 2026, a supply chain worm dubbed Mini Shai-Hulud compromised TanStack, Mistral AI, UiPath, and 160-plus other npm and PyPI packages, exfiltrating credentials and self-propagating through the ecosystem. A separate campaign in February, SANDWORM_MODE, published 19 typosquatting npm packages impersonating Claude Code, OpenClaw, and other AI-coding tools. An April 4 disclosure, MCP Connector Poisoning, named the specific payload these packages now carry: a rogue Model Context Protocol server injected into the user's IDE configuration. Once installed, the malicious MCP server runs inside the agent's trust boundary and is treated by the agent as a legitimate source of tools, prompts, and resources.

This is the agent-web supply chain attack pattern, and it is no longer hypothetical. The npm parallel has caught up.

How the attack chain works

Agent supply chain attack chain: typosquat to MCP injection A horizontal five-step attack chain. Step 1: attacker publishes a typosquatted package on npm impersonating a popular tool. Step 2: developer installs the package thinking it is the legitimate dependency. Step 3: post-install script runs with the developer's credentials. Step 4: script modifies the IDE's MCP configuration file to add a rogue MCP server. Step 5: when the AI agent next starts, it loads the new server and treats it as trusted. Arrows connect each step left to right. The final box is rendered with a pink outline to indicate the load-bearing failure point. ATTACK CHAIN · TYPOSQUAT → MCP INJECTION 1 attacker publishes typosquat claude-code-cli vs claude-code 2 developer installs via npm npm i claude-code-cli 3 post-install script runs w/ creds user-level filesystem 4 writes new MCP server to IDE config ~/.cursor/ ~/.claude/ 5 agent loads malicious MCP server as trusted

FIVE STEPS, ALL UNDER USER PERMISSIONS no exploit needed in the agent or the IDE step 5 is where the agent's trust model breaks

Notice what the chain does not require. There is no zero-day in the agent's code, no protocol-level vulnerability, no exploit of a specific MCP server. The attack succeeds because the agent's configuration file is writable by the user's processes and the agent loads MCP servers from that configuration without distinguishing between servers the user added intentionally and servers a postinstall script added on the user's behalf. That is the structural gap SANDWORM_MODE and Mini Shai-Hulud exploit at population scale.

Why this attack surface exists

The economics line up almost too neatly. There are 10,000-plus public MCP servers across fragmented registries. The cost of publishing a new npm package is essentially zero. The cost of evaluating a new package falls on the developer who installs it. IDEs auto-pick up MCP configuration from well-known paths on disk. Agents trust the configurations they're given because the spec says no more than that about what a "trusted" server is.

Between January and February 2026, researchers filed more than 30 CVEs targeting MCP servers, clients, and infrastructure — including CVE-2026-26118 against Microsoft's MCP server, CVE-2025-49596 against the MCP Inspector debugging client, CVE-2025-54136 against Cursor, and a remote-code-execution flaw in a package downloaded nearly half a million times. The April 15 OX Security advisory covered the architectural STDIO-injection class. The April 22 Google Database Toolbox disclosure covered the DNS-rebinding class. The April 4 MCP Connector Poisoning disclosure named the typosquat-plus-config-injection class. The May 12 Mini Shai-Hulud worm operationalized it at 160-package scale.

Two months. Three distinct attack classes. One ecosystem.

What the defenses look like now

The agent-web supply chain attack surface has analogues at three layers of the stack, and the defense maturity differs at each:

Layer Attack vector Defense maturity today
npm / pip package Typosquatting, malicious postinstall npm's own scanning, third-party tools (Socket, Snyk), publisher verification (uneven)
AGENTS.md / SKILL.md Malicious project context, instruction injection Almost none — no signing, no schema validator at population scale
MCP server registration Config-file injection, malicious endpoints Per-IDE auth flows (uneven), no probe-driven trust signals at the registry level

The first row is where the package ecosystem has spent the most defensive work. The second and third are where the agent ecosystem is still building the equivalent of npm's first-generation scanning. The gap is structural and known. What's new is that adversaries are now chaining attacks across the rows: a single npm typosquat produces a package install (row 1) that injects an MCP server (row 3), with no protocol-level vulnerability in either layer.

What this means for registries and gateways

The Agenstry-relevant observation is the same one we've made about MCP server conformance and about identity verification: a self-declared claim is not evidence. An MCP server entry that says "this server implements MCP correctly" is meaningfully different from "this server, when probed today, responded as a valid MCP server and was not flagged in any active malicious-package database."

For gateway operators (Uber's pattern), the implication is that the gateway has to inspect not just the MCP server itself, but the publication path of the package that configured it. A gateway that allows arbitrary MCP servers to be installed by user-level processes inside its trust boundary is one postinstall script away from a SANDWORM_MODE incident. The operational defenses (pinning install paths, requiring published allowlists, scanning the IDE configuration for unexpected entries) are the same defenses npm's enterprise ecosystem has been writing for a decade. The agent-web version is roughly five years behind.

For public registries, the pattern means the next valuable signal to publish is provenance plus probe: not just "this MCP server exists," but "this server was published by this maintainer, signed by this key, and behaved this way when probed in the last 24 hours." Each component of that signal already exists somewhere in the ecosystem. None of the current registries publishes all three.

What we're watching

Three things, observable within the next two quarters:

  1. Whether npm itself ships an AI-coding-tool publisher verification flow. A signed-maintainer requirement for packages under tags like mcp, claude-code, or cursor would close step 1 of the attack chain at the publication layer. npm has shipped similar protections for high-value namespaces in the past; the question is whether the AI-coding ecosystem crosses that threshold of attention.
  2. Whether IDEs add an explicit-confirmation step before loading a newly-added MCP server. Step 4 of the attack chain (configuration injection) succeeds today because the IDE picks up new MCP entries silently. A one-time approval prompt the first time a server appears in the config would shift the trust model in a way the user could meaningfully verify.
  3. Whether a public AI-package threat intelligence feed emerges. npm's ecosystem has active monitoring feeds for malicious-package detection. The agent ecosystem is just starting to spin up equivalents. The first one published with continuous probe data against the MCP server population will set the template.

The headline supply chain incidents of the past two months named TanStack, Mistral AI, and UiPath. The same attack pattern works against any package an AI agent installs. The defenses already exist in adjacent ecosystems; the agent-web version is the one that hasn't shipped at scale yet. The next named incident in this class will be the one that decides how fast that defense layer matures.

Sources

← Back to blog Agenstry