HackerNews中文版

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