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]
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)