2018年，一个每周下载量200万的npm包被转手给新维护者。新维护者在其中嵌入了针对比特币钱包的恶意代码。数周无人察觉——不是因为开发者粗心，而是他们信任那个熟悉的包名。

现在，MCP生态正走向同一个陷阱。而且在某些方面，它摔得更狠。

打开网易新闻 查看精彩图片

什么是"typosquatting"（域名/包名抢注）？

打开网易新闻 查看精彩图片

很简单：有人注册一个看起来几乎和知名合法包一模一样的名字。一个字符互换。多加一个连字符。把字母"o"换成数字"0"。目标是让你——或者自动化脚本，或者AI助手——安装错误的那个。

在典型的npm工作流中，这已经是严重风险。在MCP生态里，情况更糟。

当你安装一个恶意MCP服务器时，你不是只在构建步骤运行一些代码。你是在把一个活跃进程交出去，让它访问你的文件系统、环境变量、你的shell。后果不是构建失败，而是一个后门。

为什么MCP现在是特别好的攻击目标

几个因素让这个生态异常暴露：

没有中央注册表。不像PyPI或npm，没有权威的地方可以查询带验证所有权的MCP包。包散落在npm、PyPI、Docker Hub和原始GitHub仓库里，没有统一的信任模型。

大量MCP安装来自AI推荐。有人问Claude或ChatGPT"该用什么MCP服务器做X"，然后复制建议的结果。大语言模型会幻觉包名。它们能生成听起来合理、只差一个转置字符的名字。当发现机制本身都能被欺骗，你就麻烦了。

打开网易新闻 查看精彩图片

大多数安装是复制粘贴。你看完README，复制安装命令，运行。如果来源是恶意博客帖子，或者名字被微妙修改过的GitHub fork，你会错过它。

新发布者几乎没有声誉信号。在npm上，来自有多年历史、数千依赖项的账户的包会给人隐性信任。大多数MCP发布者是只有两个仓库、一周活动记录的个人。没有信号能区分合法和恶意。

攻击实际长什么样

以@modelcontextprotocol/server-filesystem——一个合法的官方包为例。攻击者可能注册：

  • @m0delcontextprotocol/server-filesystem（字母o换成数字0）
  • @modelcontextprotocol/server-filesytem（漏掉一个字符）
  • modelcontextprotocol-server-filesystem（没有作用域命名空间）

或者在mcp-命名空间：

  • mcp-github vs mcp-qithub（g→q）
  • mcp-filesystem vs mcpfilesystem（漏掉连字符）
  • mcp-browser-use vs mcp-browzer-use

一旦安装，恶意包和真包拥有完全相同的权限。如果你给了mcp-github文件系统访问权，被抢注的版本获得同样的授权。没有额外提示。没有警告。