122 Malicious MCP Packages: The Supply Chain Nobody Audited

122 packages in the Model Context Protocol ecosystem are confirmed malicious. Not typosquats or throwaway fakes. Real, name-brand MCP servers like Postman, Zapier, and Red Hat, with poisoned versions slipped into their release histories through stolen npm publish tokens.

This landed the same week MCP got enterprise-managed authorization: zero-touch OAuth through identity providers, adopted by Anthropic, Microsoft, and Okta. The protocol is becoming production infrastructure. The supply chain underneath it looks like npm in 2014.

What the data says

Three independent analyses came out between June 16 and 17, each pulling a different thread on the same problem.

Suzu Labs published a practitioner's guide (via Security Boulevard, June 17) built on a dataset of 973 npm packages whose names contain "mcp." The findings: 71% have a single maintainer. 56% were published in the last 30 days. 25% have no linked source repository. Average package age, 98 days. Nine of eleven MCP registries failed to detect malicious uploads in testing.

DugganUSA (June 16) correlated OSV's known-malicious package catalog against MCP-named packages across npm and PyPI. They found 122 confirmed malicious entries. About 52 are throwaway impostors and another 9 are researcher artifacts. The part that matters: roughly two dozen are real, maintained, name-brand MCP servers where specific versions were backdoored.

AIntelligenceHub (June 17) framed the structural problem. These aren't libraries your code calls into. They're processes you launch, with OS-level permissions, configured by JSON files that often hold live API keys. An MCP server sits directly between your AI agent and every tool the agent is allowed to use.

The packages that got hit

The DugganUSA analysis names specific compromised packages:

@postman/postman-mcp-server had 41 published versions, but versions 2.4.10 through 2.4.12 were backdoored. Aikido, Wiz, and StepSecurity attribute it to the Shai-Hulud 2.0 campaign.

@zapier/mcp-integration, versions 3.0.1 through 3.0.3, same campaign.

@antv/mcp-server-chart: 44 versions, eighteen maintainers, versions 0.10.10 and 0.11.10 were poisoned. Socket and SafeDep tie it to TeamPCP's "314 packages" sweep.

Red Hat's MCP namespace: three packages Wiz disclosed on June 1 as part of the Miasma worm family.

mcp-use, the popular open-source MCP framework itself: versions 1.4.2 through 1.4.3 of the core package were compromised.

The attack pattern repeats every time. Steal a maintainer's npm publish token, ship a malicious version of a package people already trust, and let the next npm update deliver it. The user installed the package on purpose. The attacker didn't need them to mistype anything.

2,117 live credentials in config files

GitGuardian's 2026 State of Secrets Sprawl report, released the same week, scanned public GitHub for MCP configuration files. They found 24,008 unique secrets in plaintext: API keys, database connection strings, OAuth tokens. 2,117 were confirmed still live at scan time. The credential still worked. The API key still authenticated. The database still responded.

The threat actor group tracked as WAVESHAPER has been observed specifically enumerating MCP config files in public repositories. The pattern is automated and opportunistic. Once an attacker has a working API key, the resulting activity looks like your legitimate agent. It is your agent, just called by someone else.

Why MCP is different from npm

A regular npm dependency is a library your code calls. An MCP server is a process you launch, running with your agent's permissions, executing whatever commands the agent decides to pass it.

The STDIO transport that most MCP servers use passes configuration parameters directly into OS-level command execution without input validation. OX Security disclosed this as a design-level issue. Anthropic called it expected behavior, and the protocol spec doesn't require validation.

That's fine for a local developer tool. When the same code path runs on shared infrastructure or inside a production agent deployment, the blast radius widens.

The security tooling gap compounds this. For every download of an AI security tool on npm, there are 28 downloads of an AI coding tool. On PyPI, the ratio is 10:1. CVEs filed against AI coding tools and MCP-adjacent libraries grew from 3 in 2023 to 51 in 2025. 78% are rated CRITICAL or HIGH in the National Vulnerability Database.

What to do this week

The practical guidance is the npm 2014 playbook, adapted for agents:

Pin versions and use a lockfile. The poisoned releases are narrow version ranges. The rest of each package's history is clean, and latest versions have been remediated. Floating tags like @latest are the delivery mechanism.

Cross-check installed versions against the flagged ranges. If you pulled any of the packages listed above during the compromise windows, rotate your tokens and assume harvest.

Keep MCP config files out of version control. Treat them the way you treat private keys. Any secret that touches a public repo should be considered compromised.

Run MCP servers in least-privilege containers with a read-only filesystem. A compromised server that can't write outside its sandbox has limited room to operate.

Prefer packages with multiple maintainers and a public source repository. The 25% of MCP packages with no linked source repo give you nothing to audit.

None of this is new in principle. All of it is underinvested relative to the pace at which teams are deploying AI agents.

Sources: AIntelligenceHub, DugganUSA, Security Boulevard / Suzu Labs, GitGuardian State of Secrets Sprawl 2026, OX Security / CSA.