🚨 Security Warning for MCP Server Developers and Users: Systematic Forking as a Supply-Chain Attack Vector

[CSCSoftware]

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)

[raye-deng]

This is a great write-up and an important warning. The forking-and-republishing pattern you describe is essentially the same trust problem we see with AI-generated code — but at a different layer.

In our experience building CI tooling for AI-assisted development, one of the most common failure modes is what we call "phantom dependencies": an AI coding assistant generates an import for a package that looks plausible (familiar name, reasonable scope) but either does not exist on the registry, has been renamed, or — worst case — has been published by someone other than who you would expect.

The MCP supply-chain scenario you describe is the deliberate exploitation of this exact trust gap. And you are right that MCP servers are particularly dangerous because of the filesystem and credential access they get.

One practical addition to the defenses you listed: a CI-level registry validation step that checks every dependency against a known-good allowlist or verifies publisher identity before install. We added this to our scanner after seeing AI tools auto-install packages from unfamiliar scopes without any verification. It catches both the accidental case (AI hallucinated a package name) and the malicious case (typosquatting / scope impersonation).

For anyone wanting to add this kind of check to their pipeline: npx @opencodereview/cli scan . --sla L1 — it validates imports against actual registries as part of the PR review.