HackerNews中文版

我是一个MCP服务器的开发者（AiDex — 使用Tree-sitter进行代码索引，github.com/CSCSoftware/AiDex）。我最近发现一个名为iflow-mcp的组织正在系统性地在GitHub上分叉数百个MCP服务器，并在他们自己的npm命名空间（@iflow-mcp/）和PyPI上重新发布这些项目，同时通过他们自己的“市场”进行分发——而从未联系过原作者。但真正的问题并不是分叉本身，而是安全性。 --- *发生了什么* 这些分叉以@iflow-mcp/originalauthor-projectname的模式发布。原作者的熟悉名称创造了信任——但用户实际获得的代码完全在第三方的控制之下。没有任何东西可以阻止该第三方在发布之前修改代码。 *为什么MCP服务器特别危险* MCP服务器并不是一个无害的插件。根据设计，它具有深层访问权限： - 它读取你的源代码，浏览你的文件系统，接收文件内容 - 它可以看到.env文件、API密钥、SSH密钥、凭证和专有代码 - 它通过标准输入输出直接与AI客户端通信——这意味着它可以操控工具的响应 - 它通常以与用户相同的权限运行一个被植入木马的MCP服务器可以在正常执行其功能（如索引或分析你的代码）的同时，悄悄地提取敏感数据。你看到工具正常工作，但却看不到数据的流出。更糟的是，一个被操控的服务器可能故意向AI助手提供虚假信息——建议不安全的代码模式、隐藏漏洞，或者将AI引导到错误的文件。 *信任链的破裂* 这个问题是系统性的： 1. 开发者A将一个MCP服务器作为开源项目发布 2. 组织X对其进行分叉，并在他们自己的命名空间下重新发布 3. 用户在X的市场中找到该包，认出熟悉的名称并安装它 4. 用户认为他们正在运行原版——但实际上他们运行的是X可能以任何方式修改过的代码这是一种经典的供应链攻击。而且它特别有效，因为MCP服务器是新的，许多用户尚未学会验证他们的工具实际来源。 --- *作为MCP服务器开发者你可以做什么* 1. *启动时的来源检查：* 检查你自己的包名（package.json，process.env.npm_package_name）和安装路径（__dirname）。如果出现外部命名空间，显示明确的警告： ``` 这似乎是[项目]的非官方再分发。官方包：npm install [original-package] 仓库：[original-url] ``` 2. *构建签名：* 在构建过程中嵌入哈希或签名标识符。一个不复制你确切构建流程的再发布者无法重现它。 3. *注册表检查：* 启动时向npm注册表发送快速HTTP请求，可以揭示该包是否在外部命名空间下运行。 *作为用户你可以做什么* - 始终直接从原始项目安装MCP服务器，绝不要通过第三方市场 - 检查npm命名空间：@iflow-mcp/cscsoftware-aidex与aidex-mcp并不相同 - 查看GitHub以验证一个仓库是否是分叉，以及实际作者是谁 - 对具有深层文件系统访问权限的MCP服务器特别谨慎 --- *请分享这篇帖子。* 越多的MCP开发者和用户了解这种攻击方式，利用它的难度就越大。MCP生态系统正在快速增长——但如果没有对供应链安全的意识，我们就是在沙子上构建。如果你受到影响：请发声。检查你的项目是否出现在github.com/iflow-mcp/下。声音越多，npm和GitHub采取行动的速度就越快。原始项目：https://github.com/CSCSoftware/AiDex 他们在npm上的分叉：https://www.npmjs.com/package/@iflow-mcp/cscsoftware-aidex —— Uwe Chalas，AiDex的作者（npm上的aidex-mcp）

查看原文

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 userA 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 wayThis 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:<pre><code> This appears to be an unofficial redistribution of [project]. Official package: npm install [original-package] Repository: [original-url] </code></pre> 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)

MCP 服务器被大规模分叉并重新发布 – 供应链攻击向量