MCP servers mass-forked and republished – supply-chain attack vector

2 points

3 months ago

I'm the developer of an MCP server (AiDex — code indexing with Tree-sitter, github.com/CSCSoftware/AiDex). I recently discovered that an organization called iflow-mcp is systematically forking hundreds of MCP servers on GitHub, republishing them under their own npm scope (@iflow-mcp/) and on PyPI, and distributing them through their own "marketplace" — without ever contacting the original authors.

But the real problem isn't the fork itself. The real problem is security.

---

*What's happening*

The forks are published under the pattern @iflow-mcp/originalauthor-projectname. The familiar name of the original creates trust — but the code the user actually gets is entirely under a third party's control. Nothing prevents that third party from modifying the code before publishing.

*Why MCP servers are particularly dangerous*

An MCP server is not a harmless plugin. By design, it has deep access:

- It reads your source code, navigates your filesystem, receives file contents - It can see .env files, API keys, SSH keys, credentials, and proprietary code - It communicates via stdio directly with the AI client — meaning it can manipulate tool responses - It often runs with the same permissions as the user

A trojanized MCP server could silently exfiltrate sensitive data while doing exactly what it's supposed to do — indexing or analyzing your code. You see the tool working normally. You don't see the data leaving.

Even worse: a manipulated server could feed the AI assistant deliberately false information — suggesting insecure code patterns, hiding vulnerabilities, or redirecting the AI to the wrong files.

*The broken chain of trust*

The problem is systemic:

1. Developer A publishes an MCP server as open source 2. Organization X forks it, republishes it under their own scope 3. A user finds the package in X's marketplace, recognizes the familiar name, installs it 4. The user believes they're running the original — but they're running code that X could have modified in any way

This is a classic supply-chain attack. And it works particularly well because MCP servers are new, and many users haven't yet learned to verify where their tools actually come from.

---

*What you can do as an MCP server developer*

1. *Origin check at startup:* Check your own package name (package.json, process.env.npm_package_name) and installation path (__dirname). If a foreign scope appears, display a clear warning:

    This appears to be an unofficial redistribution of [project].
   Official package: npm install [original-package]
   Repository: [original-url]

2. *Build signature:* Embed a hash or signed identifier during your build process. A republisher who doesn't replicate your exact build pipeline cannot reproduce it.

3. *Registry check:* A quick HTTP request at startup to the npm registry can reveal whether the package is running under a foreign scope.

*What you can do as a user*

- Always install MCP servers directly from the original project, never through third-party marketplaces - Check the npm scope: @iflow-mcp/cscsoftware-aidex is NOT the same as aidex-mcp - Look at GitHub to verify whether a repository is a fork and who the actual author is - Be especially cautious with MCP servers that have deep filesystem access

---

*Please share this post.* The more MCP developers and users know about this attack vector, the harder it becomes to exploit. The MCP ecosystem is growing rapidly — but without awareness of supply-chain security, we're building on sand.

If you're affected: speak up. Check whether your project appears under github.com/iflow-mcp/. The more voices, the sooner npm and GitHub will act.

Original project: https://github.com/CSCSoftware/AiDex Their fork on npm: https://www.npmjs.com/package/@iflow-mcp/cscsoftware-aidex

— Uwe Chalas, author of AiDex (aidex-mcp on npm)

2 comments