Examining the impact of npm supply chain attacks on MCP

Last week, a significant supply chain attack hit the JavaScript/TypeScript ecosystem through the npm registry. Multiple widely used packages, collectively downloaded more than 2 billion times per week, were compromised via a single maintainer’s npm account.

Malicious versions of debug, chalk, ansi-styles, and 15 other packages were published. The payload focused on stealing cryptocurrency wallets, but the incident underscored a broader, ongoing risk: the open source supply chain is a high-value target.

And it didn’t stop there. This week, another campaign dubbed "Shai-Hulud" targeted additional npm packages, this time exfiltrating sensitive data and attempting self-propagation across the ecosystem.

Plenty has already been written about these attacks. Here, I’ll focus on the impact on the Model Context Protocol (MCP) ecosystem. A quick scan of npm-based MCP servers showed that a significant percentage were at risk.

Why were so many MCP servers exposed?

The compromised packages are foundational in the JavaScript/TypeScript ecosystem. For MCP specifically, they are indirect dependencies of the official MCP TypeScript SDK. Any MCP server built from the SDK was therefore potentially vulnerable.

Most JS/TS MCP servers are run by clients with npx, which executes arbitrary commands from npm packages. During execution, all direct and transitive dependencies are pulled down to the local system. Unless wrapped in a Docker container, the server inherits the same access you have to your machine, networks, and data.

What should MCP users do?

Fortunately, the malicious versions were quickly identified and removed, limiting downstream damage. But assume the worst and take proactive steps:

• Check and update the versions of MCP packages you use.
• Clean your npm/npx cache (npm cache clean --force) and restart your MCP clients.
• Pin package versions instead of defaulting to @latest.

Looking forward, apply the same discipline you would for any code you run locally:

• Keep MCP servers up to date.
• Prefer servers that are actively maintained.
• Favor containerized MCP servers to limit their blast radius.

What should MCP server maintainers do?

If you maintain an npm MCP server, rebuild and publish a fresh version, even if you don’t think you were affected. The cost is low, and it eliminates the chance that a malicious dependency slipped in during the attack window.

Longer term, there are best practices every maintainer should follow:

• Audit dependencies regularly with npm audit or similar tools.
• Automate updates of direct and indirect dependencies with tools like Dependabot.
• Pin direct dependency versions.
  • Be cautious: these attackers used patch releases, so even a narrow version range like ~1.2.3 would have matched.
• Check your lock file into version control so builds are reproducible.
• Offer containerized builds of your MCP server.

ToolHive: a secure approach to MCP

At Stacklok, we’re working to secure MCP servers via our open source project, ToolHive.

We’ve made deliberate choices in the design and development of ToolHive with security in mind. For example, one of our earliest architectural decisions was to require containerization for MCP servers.

We re-package a curated set of MCP servers as container images in the ToolHive registry. When we learned about this attack, we proactively rebuilt these images as soon as the malicious packages were removed from the npm registry. For third-party images in our registry, we use strict version pinning, ensuring users didn’t pull potentially vulnerable releases during the attack window.

Containerization brings runtime consistency and portability, but more importantly, it limits exposure: a compromised MCP server is isolated from the rest of your system.

ToolHive goes further by including network isolation. You can restrict outbound access so MCP servers only connect where they need to. Safe defaults are built into the registry. For example, the GitHub MCP server can be protected with a single CLI flag or UI toggle:

thv run --isolate-network github

Conclusion

The npm supply chain attack of September 8, 2025 reached deep into the MCP ecosystem. The actual impact depended on how servers were developed and deployed. Container isolation, and especially when combined with network isolation, proved to be an effective defense.

This isn’t about a single tool. It’s a reminder that security has to be baked into how we develop and run software. Supply chain attacks will continue to evolve. Our practices must evolve faster.