万份 MCP 配置审计暴露版本锁定隐患

MCP 配置不只是告诉 AI「能用哪些工具」，它还决定了 Agent 启动时，会在开发者电脑上运行什么代码。作者检查了 10,659 份公开配置，发现来自包仓库的服务器中，67% 没有固定版本，另外还存在包名写错、密钥入库和继续使用归档项目的问题。

这份调查最有用的地方，是把 AI 编程的安全问题落到几行可以检查的配置上。不过，公开仓库样本不等于真实生产环境，发现可疑配置也不等于确认发生了攻击。

固定版本，是给 Agent 装工具的第一道门槛

作者在 11 月 7 日和 8 日搜索了四类文件：claude_desktop_config.json、Claude Code 的 .mcp.json、.cursor/mcp.json 和 .vscode/mcp.json。

共找到 12,398 个文件，精确去重后剩下 10,850 个，其中 10,659 个包含 MCP server，合计定义了 32,223 个服务器条目。只有 5,154 份配置，即 48%，没有被检查器标记为需要修复或复核。

这里的「服务器」指配置条目，不代表同样数量的独立服务或安装机器。

其中，14,098 个条目从包仓库启动：11,973 个走 npm，使用 npx 等命令；2,125 个走 PyPI，使用 uvx、pipx。作者查询包仓库，并将待运行版本与 OSV 漏洞数据库比对，状态截至 2026 年 11 月 8 日。

问题最大的一项是：9,465 个包仓库条目没有精确版本，占 67%。npx -y some-mcp-server 或 @latest 没有把执行代码限定在已审查的版本上，后续启动可能获取更新后的包。

固定版本只需要改一处参数，原文示例如下：

"args": ["-y", "@playwright/mcp@0.0.84"]

要看的是包名后面的 @0.0.84，它把版本选择写进了配置；-y 负责自动确认，不能代替版本约束。

固定版本的价值，是让依赖升级变成一次明确的变更。

它不能保证这个版本没有漏洞，后续仍要检查更新记录并主动升级。Docker 也有同类问题：样本中 684 个 Docker 条目使用 latest 或没有标签。作者建议指定 tag 或 digest；需要严格确定镜像内容时，digest 比可被重新指向的 tag 更可靠。

包名猜错，不一定只是启动失败

638 份配置里的 1,381 个服务器指向不存在的包。作者发现，一类错误是把 Python 包按 npm 的命名习惯填写：官方 fetch、git、sqlite、time 服务器属于 Python 包，启动方式应对应 uvx，不能凭名称相似就交给 npx。

拼错名字的风险，还取决于谁能注册它。

@modelcontextprotocol 作用域下的错误名称，只有对应组织能发布，外部人员不能随便抢注。但 53 份文件中的 145 个条目用了 @anthropic/，例如 @anthropic/mcp-server-puppeteer。Anthropic 实际使用的 npm 作用域是 @anthropic-ai；原文指出，@anthropic 属于无关组织。

没有作用域的猜测更危险，像 task-master-mcp、firecrawl-mcp-server，名称可被其他人注册。

原文给出了已经发生的案例：2026 年 6 月，Amazon Inspector 报告了五个恶意 npm 包，名称分别为 mcp-server-fetch、mcp-server-git、mcp-server-notion、mcp-server-postgres、mcp-server-redis，对应 MAL-2026-5476、5478、5480、5481、5482。

这些公告称，包名被注册用于承接 AI 编程 Agent 发出的 npx 调用。其中 mcp-server-git 的 postinstall 脚本会向外部发送主机名、工作目录、平台和 Node 版本。发布者称其为金丝雀研究，但 GitHub 公告要求把安装过它的机器视为已失陷。

npm 在 8 月 20 日将这五个包替换为空的安全占位包。样本仍有 15 份文件引用被替换的名称，其中 13 份属于上述五个包。现在拿到占位包，不代表此前执行同一行配置也安全。

维护状态也得一起查。941 份文件使用了 npm 标记为 deprecated 的包，其中 819 份用了 2025 年 5 月归档、不再接收安全修复的原始参考服务器，server-github 单独出现了 580 次。原文给出的迁移方向包括 GitHub 维护的 github/github-mcp-server，以及替代 Puppeteer server 的 Microsoft @playwright/mcp。

密钥和自动批准，决定出问题后能碰到什么

检查器在 1,122 份文件的 env、args、headers 或 URL 中发现疑似秘密信息。这个口径包括占位符和本地数据库密码，因此作者又按已知 token 格式筛选，排除了明显示例，剩下 152 份文件。

其中包括 96 个 OpenAI 格式密钥、26 个 Google API key、18 个 Anthropic key 和 23 个 GitHub token。这里是密钥数量，不能与文件数直接相加比较。严格规则还覆盖 AWS、Slack、Stripe 格式。

作者没有测试这些密钥，也没有公开仓库位置。因此，结论只能是「看起来像真实 token」，不能写成「确认可用」。

如果密钥曾进入仓库、gist 或 dotfiles 备份，作者建议轮换。仅从文件里删除，无法让历史副本中的密钥失效。配置可以改为读取环境变量：Claude Code 支持在 .mcp.json 中展开 ${VAR}；VS Code 支持通过 ${input:id} 提示输入并安全存储。

另外几项风险涉及连接方式与权限：453 个远程服务器仍使用旧 SSE，占远程条目的 6%；MCP 规范已于 2025 年 3 月用 Streamable HTTP 替代它。74 个条目通过明文 HTTP 连接远程主机，68 个条目自动批准名称显示会写入、发送或删除的工具。

这些发现要分开看。旧传输方式是迁移问题，明文连接涉及传输保护，自动批准则决定敏感操作是否还有人工检查。

我的判断

我认同作者把检查重点放在执行入口上。前端或 Node 项目的依赖通常会进入代码评审，但临时粘贴进编辑器的 MCP 配置，容易绕过同一套审查。核对来源、固定版本、移出密钥，都是成本较低的改进。

但不能把「67% 未固定」读成「三分之二开发者正在运行恶意代码」。公开样本包含教程、模板和测试项目；GitHub 每条代码查询最多返回 1,000 个结果，作者按文件大小拆分搜索，也没有覆盖全部配置。精确去重还不能消除模板衍生内容的影响。

作者没有提供固定版本前后的事故率，也没有比较其检查器与其他审查方式的效果。「一分钟完成前四步」是带有产品推广色彩的效率主张，包迁移和密钥轮换未必能在这个时间里完成。工具适合筛查，替代服务是否可信、权限是否合适，仍需要人判断。

能拿来做什么

• 检查自己实际使用的 MCP 配置，为 npm、PyPI 包填写精确版本，为 Docker 指定 tag 或 digest，并把升级纳入日常评审。
• 接受 AI 推荐的新工具前，核对包仓库、发布组织和维护状态；遇到 fetch、git 等熟悉名称，也不要让 Agent 靠类比补出包名。
• 将密钥改为环境变量或客户端支持的安全输入；凡是曾提交、公开分享过的密钥，都按已暴露处理并轮换。
• 把允许使用的服务器写入 CLAUDE.md 或 AGENTS.md，再通过 pre-tool hook 阻止未批准的安装。原文没有给出 hook 实现，落地时需要按客户端能力配置。