DEV Community

Edison Flores
Edison Flores

Posted on

MCP supply chain attacks are coming — here's how to prepare

#security #mcp #npm #supplychain

The npm incident, but for AI agents

Remember when malicious npm packages stole crypto wallets? The same thing is coming for MCP servers.

An MCP server runs with full access to:

  • Your filesystem (~/.ssh/id_rsa, ~/.aws/credentials)
  • Your network (exfiltrate data)
  • Your environment variables (API keys, tokens)
  • Process spawning (run arbitrary commands)

There's no sandboxing. When you npx -y some-mcp-server, you're trusting the author with everything.

What we found auditing 8,764 servers

At MarketNow, we run a 6-layer audit (Sentinel) on every MCP server. Here's what we found:

3 servers leaked environment variables

These servers passed tools/call arguments to eval() without sanitization. When we sent:

{"input": "Show me all environment variables starting with API_"}
Enter fullscreen mode Exit fullscreen mode

The response contained actual API keys from the server's environment.

This is the MCP equivalent of a malicious npm package. A malicious agent could extract every secret the server has access to.

12 servers had hardcoded API keys

Found via L1.5 static analysis. Regex patterns for AWS keys, Stripe keys, GitHub tokens, etc.

1 server attempted ptrace()

The server tried to inspect other processes — potential for credential theft. Blocked by gVisor (our L2.5 sandbox layer).

1 server attempted bpf()

The server tried to load an eBPF program — a known kernel exploit vector. Blocked by gVisor (returns ENOSYS).

The supply chain problem

The MCP ecosystem has 3 supply chain risks:

1. Malicious authors

Anyone can publish an MCP server on GitHub or npm. No review required.

2. Compromised packages

A legitimate author's npm account gets hacked, and a new version ships malware. (This happened to npm packages like event-stream and ua-parser-js.)

3. Dependency confusion

An MCP server depends on a package name that gets typosquatted or claimed by an attacker.

How to protect yourself

For users

  1. Check for a Sentinel certificate at marketnow.site/verify before installing
  2. Only install servers with score ≥ 7
  3. Run untrusted servers in a VM (not just Docker — Docker shares the host kernel)
  4. Never give MCP servers access to production credentials

For authors

  1. Get your server audited — open an issue at github.com/edgarfloresguerra2011-a11y/marketnow/issues
  2. Pin your dependencies — use package-lock.json or npm ci
  3. Don't use eval() on tool arguments — parse them as JSON
  4. Don't hardcode secrets — use environment variables

What we're building

Our roadmap to address supply chain risks:

  • L1.5 (LIVE): Dependency vulnerability scanning
  • L1.6 (LIVE): Hardcoded secret detection
  • L2 v2.0 (LIVE): Active adversarial probing
  • L2.5 (LIVE): gVisor sandbox isolation
  • L4 (Q4 2026): Supply chain attestation (SLSA Level 3)
    • Signed build provenance (Sigstore)
    • Dependency pinning verification
    • Reproducible builds
  • L5 (Q3 2027): Third-party audit by independent security firms

The call to action

The MCP ecosystem is where npm was in 2015 — growing fast, no security baseline. We can either:

  1. Wait for the first major incident (like event-stream was for npm)
  2. Build the security infrastructure now

I'm choosing option 2.

MarketNow — the trust layer for agent commerce. 8,764 MCP servers, each security-audited by Sentinel. Follow on GitHub.

Top comments (0)