MCP servers mass-forked and republished – supply-chain attack vector
3 comments
This is a real problem and it's going to get worse as the MCP ecosystem grows. The supply chain trust issue is structurally identical to what npm faced in 2018-2020 and the stakes are higher because MCP servers have filesystem access by design.
The origin check approach you described is a good defensive measure, but it's ultimately opt-in and fragile. What the ecosystem actually needs is provenance signing at publish time so any client can verify that the binary they're running was signed by the same key as the original author, regardless of which marketplace or scope it came through.
Ed25519 signatures are 32 bytes and fast to verify. It's not a hard problem technically it's a coordination problem. Someone needs to establish the standard before the ecosystem gets big enough that bad actors have real incentive.
The origin check approach you described is a good defensive measure, but it's ultimately opt-in and fragile. What the ecosystem actually needs is provenance signing at publish time so any client can verify that the binary they're running was signed by the same key as the original author, regardless of which marketplace or scope it came through.
Ed25519 signatures are 32 bytes and fast to verify. It's not a hard problem technically it's a coordination problem. Someone needs to establish the standard before the ecosystem gets big enough that bad actors have real incentive.
Welcome to life with agentic coding, it makes it super easy for the grifters
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:
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)