MCP Rug Pull Attacks: When Trusted Tools Turn Malicious

A rug pull attack is when a tool or package works perfectly fine in development, passes all your security reviews, gets adopted into production, and then the maintainer pushes a malicious update. By that time, you're pinning your code to that tool, trusting it with sensitive operations, and running the latest version automatically.

This is one of the most dangerous attack vectors in MCP deployments, and it's becoming increasingly common. Here's why it happens and what you can do about it.

How MCP Rug Pulls Differ from Traditional Supply Chain Attacks

Traditional supply chain attacks target libraries and dependencies. An attacker compromises a package, injects malicious code, and users who update get pwned. This has happened in npm, PyPI, and other ecosystems many times.

MCP rug pulls are different. They're not even that subtle. The typical attack flow:

1. Attacker publishes a legitimate-looking MCP server to npm: @my-org/mcp-server
2. Tool descriptions are clean, schema is tight, behavior is safe
3. Teams adopt it, test it, trust it, deploy it to production
4. Attacker pushes version 1.0.5 with poisoned tool descriptions or malicious behavior
5. Because teams use npx -y @my-org/mcp-server, they automatically get the latest version
6. The poisoned tool runs, and the attack succeeds

The difference is that MCP makes this trivial. There's no compiled binary to verify, no checksum to compare. Just run the latest code.

The npx -y Problem

This is the root cause. When you run:

NPM fetches the latest version from the registry, every single time. You have no control over what version runs. You can't pin it. You can't hash-verify it. You just trust that whatever the registry has is safe.

If the maintainer (or an attacker who compromised the maintainer's account) pushes a malicious version, you get it automatically.

This is different from npm dependencies in package.json, where you can pin versions. npx -y ignores all that. It's "run the latest code I can find on the internet."

Real-World Parallels

This isn't speculation. The npm ecosystem has seen this exact attack many times:

• event-stream (2018): A popular npm package was compromised. The attacker added malicious code that stole Bitcoin private keys. Thousands of projects were affected.
• ua-parser-js (2021): Another widely-used library was compromised. The attacker added cryptocurrency miners and password stealers.
• Numerous account takeovers: Package maintainers' npm accounts are compromised regularly, leading to malicious package versions.

In each case, the attack worked because users were installing the latest version without verification. The same conditions exist in MCP deployments.

MCP-Specific Risks

MCP rug pulls are particularly dangerous because:

• Tool definitions change at runtime: You can't pre-scan the package, because the tool definitions come from whatever version is running. A clean version 1.0.0 can become malicious in 1.0.1.
• Tools have broad permissions: MCP servers often have access to files, databases, APIs, and network. A rug-pulled tool can do real damage.
• No audit trail: Unless you're logging every tool call, you won't know when the tool's behavior changed.
• Adoption is fast: Teams copy the quick-start from docs: "just run npx -y." They don't think about what it means.

Detection Strategies

Pin Versions Instead of Using -y

Don't use npx -y. Install the package explicitly and pin the version:

Store the pinned version in your package.json or MCP configuration. Review new versions before updating. If a version looks suspicious, don't upgrade.

Hash/Checksum Verification

NPM supports integrity hashes. Store the hash of the version you trust:

Store this hash in your configuration or CI/CD pipeline. Before running a tool, verify that the installed package matches the hash you expect.

Regular Re-Scanning

Use Ferrok to scan your MCP server's tool definitions regularly, not just once at setup. If you use Ferrok's CI/CD integration, you can catch rug pulls that happen after deployment:

If a new version introduces poisoning, Ferrok will detect it. Your CI/CD pipeline will alert you before the code runs.

Version Pinning and Monitoring

Tools like Snyk and Dependabot monitor your dependencies for known vulnerabilities. But they don't catch 0-day rug pulls (attacks that aren't yet known). However, pinning versions plus regular scanning is the next best thing: you're not auto-updating, and you're actively monitoring for changes.

Protection Strategy

There's no perfect defense against rug pulls. But you can make yourself a hard target:

1. Pin versions. Don't use -y or latest. Pin to specific releases.
2. Store hashes. Keep the SHA of the version you trust. Verify before running.
3. Scan regularly. Use Ferrok to scan your tool definitions on a schedule. Catch poisoning early.
4. Review updates. When a new version is released, review the changelog and the tool definitions. Don't auto-upgrade.
5. Monitor behavior. Log tool calls. If a tool's behavior changes unexpectedly, alert.
6. Audit dependencies. Know what packages your MCP servers depend on. Use tools like npm audit to flag transitive dependencies with known issues.

The Bottom Line

Rug pulls happen when trust is exploited. In the MCP ecosystem, that trust often comes from the default installation method: download and run the latest code. The fix is to change how you install and update MCP tools: pin versions, verify hashes, scan regularly, and review changes before upgrading.

This isn't a technical lock; it's a process. But processes are how teams survive supply chain attacks.