MCP 依赖漏洞对比：如何读懂生态差异

选 MCP server 时，除了功能和接入方式，还该看看它会把哪些依赖装进来。作者检查了一批 npm、PyPI 服务所列版本的完整依赖树：有明确结果的记录中，npm 的「未发现已知公告」占 50.4%，PyPI 占 92.5%。

差距很大，但不能直接推出「Python 更安全」。这组数据更适合用来提醒安装前该查什么，以及区分三个容易混淆的问题：依赖有没有漏洞公告、服务能不能被利用、检查结果是否仍然有效。

50.4% 和 92.5% 到底在比较什么

报告基于 2026-10-23 的 registry 快照，目录共有 48,551 条记录，依赖树检查发生在 2026-10-24。其中，15,686 条得到明确结果，占适用检查记录的 96.3%。

作者的做法是：解析每条记录所列版本的依赖树，对照已发布的漏洞公告，再取整棵树中最高的严重等级作为该记录的结果。它检查的不只是 MCP server 自身，也包括安装时带进来的间接依赖。

在有明确结果的记录中，npm 有 50.4% 未发现已知公告，PyPI 为 92.5%。严重程度的分布也不同：npm 的命中结果几乎都落在 high；PyPI 则是 critical 的 138 条多于 high 的 79 条。

全部 15,686 条明确结果的分布如下：

最高严重等级	记录数	占比
critical	261	1.7%
high	5,550	35.4%
moderate	169	1.1%
low	17	0.1%
none known	9,689	61.8%

这里的百分比以有明确结果的记录为分母。比如 npm 的 11,756 条记录中，只有 11,459 条成功得到结果，其余依赖树解析失败的记录被排除，不能算作「干净」。

依赖命中公告，离服务可被攻击还有多远

依赖树里存在已知漏洞，不等于这个 MCP server 已经被证明可以利用。

公告命中说明：解析出来的某个依赖版本落在公告影响范围内。服务是否调用受影响的函数、实际运行条件能否触发问题，还需要另外检查。作者明确说，没有分析代码是否会执行到这些受影响的函数。

反过来，none known 也只是「这次检查没有找到已知公告」，不能当成安全保证。公告数据库每天都在变化，同一棵依赖树，下周可能得到另一种结果。

还有两类边界容易漏掉。远程 MCP server 运行在供应商机器上，不交付可供检查的安装包，因此不在这张表里。只查询包名也不够，那只覆盖包本身；文中的数字来自单独执行、成本更高的依赖树检查。

因此，这份报告回答的是一个有限的问题：在指定日期、按指定方式解析出的依赖中，最高等级的已知公告是什么。

为什么不能拿它给两种语言排安全名次

两列数据的生成方式并不完全相同。npm 使用仅生成 lockfile 的依赖解析方式，PyPI 则在固定 Python 版本的条件下运行解析器。原文没有给出具体 Python 版本和执行命令。

作者也没有测量：差距有多少来自生态习惯，有多少来自依赖树规模，又有多少来自工具差异。因而，数据支持「这批记录的检查结果存在差异」，不支持直接解释差异的原因。

还有一个选型层面的区别：你最终安装的是某个服务的某个版本，并不是生态的平均值。PyPI 的总体比例更好，不能替代对目标包的检查；npm 约一半明确结果命中某种等级的公告，也不能证明你选中的服务一定有问题。

我的判断

我赞同作者把检查日期、分母和解析失败记录一起交代。这些信息决定了百分比能怎么用。尤其是没有把「查不出来」归入「没有漏洞」，让结果保留了必要的边界。

但这份报告仍是依赖公告筛查，不是完整的安全评估。它没有提供漏洞可利用性的验证，也没有提供控制依赖规模、解析环境等条件后的对照数据。不能用它证明某种语言天然更安全。

与只查包名相比，完整依赖树检查覆盖得更广；与逐项分析调用路径相比，它又适合作为初筛。对程序员来说，合理顺序是先用公告筛出需要关注的依赖，再判断它们是否影响实际使用，而不是看见 high 就直接下结论。

能拿来做什么

• 给编辑器或 AI 编程工具接入 MCP server 前，检查准备安装的具体版本，并覆盖间接依赖。npm 和 PyPI 都应执行自己的审计。
• 查看目录中的单条服务记录。每页九项检查中，有一项专门检查包及其依赖是否存在已知 critical 或 high 公告；它通过了，也不代表完全没有其他等级的公告。
• 遇到公告命中时，继续核对受影响功能与服务调用路径。遇到解析失败时，把它保留为待查项，不要当作检查通过。
• 保存检查日期、目标版本和解析环境，并在后续重新检查。2026-10-24 的结果不能替之后的安装决定提供长期保证。