MCP服务器依赖漂移隐患
即便配置为运行单一固定版本的模型上下文协议（MCP）服务器，其底层依赖环境也可能发生不可控的漂移。Corelight技术联盟总监James Lagermann在公司实验室中发现，一台未被触碰配置的MCP服务器在四周内使用了15组不同的依赖项。该服务器包含的69个软件包中，有23个发生了版本变更，涉及加密库、JSON Web Token库以及MCP软件开发工具包本身。
MCP服务器允许AI编程助手代表用户操作其他工具，通常持有用户凭证。在该工作站内，这些服务器一周内向防火墙、安全信息和事件管理（SIEM）系统及传感器管理系统等11个管理系统建立了超过1,600次连接。若依赖项中混入恶意代码，攻击者将获得这些敏感访问权限。
固定措施为何失效
此类助手通常使用uvx启动服务器，该启动器从单行配置中下载并运行Python软件包。尽管配置指定了确切的发布标签、PyPI版本或Git提交哈希，但对于部分社区服务器，启动器会从声明依赖关系中安装，并跳过项目中哈希固定的锁文件（lock file）。这意味着环境重建时，约60个软件包会从Python软件包索引（PyPI）重新解析。仅固定主包版本，并不能固定其下游依赖。
数据显示，该助手在一周内启动了同一服务器162次。虽然大多数启动复用了缓存环境，但缓存中仍保留了同一发布版本和提交的19个构建版本，大约每两天更新一次。这种高频更新至关重要，因为被劫持的版本可能仅存活几分钟或几小时。例如，2026年6月，PyPI上曾出现针对MCP主题软件包的Shai-Hulud蠕虫变体，试图窃取AI编程助手密钥。
实地部署普遍存在风险
Corelight审查了两个供应商目录及其实验室中的35个MCP服务器，发现其中23个在推荐安装过程中，每次启动、安装或镜像构建时都会从公共注册中心拉取依赖项。
Lagermann指出，实地环境中也存在相同模式。“我在客户环境和其他实际部署中看到了同样的情况。截至目前，我所交谈过的所有管理员都在使用至少一个存在此问题的MCP服务器。”
冻结版本需配合持续维护
测试显示，冻结措施有效但需人工维护。Corelight对五个服务器实施冻结：固定到特定提交版本，从哈希固定的锁文件中一次性安装，直接启动并关闭更新检查。随后两周内，这五个服务器共启动457次，安装的软件包列表与初始记录完全一致。
然而，冻结的代码会随时间老化。测试中，被冻结的社区服务器其40个软件包比启动器当天拉取的版本更旧，部分涉及安全敏感问题。Lagermann建议遵循MCP维护者的更新建议：“我维护的MCP服务器每晚进行漏洞审查，若发现漏洞，次日早上即更新并附带变更日志。”
目前，Lagermann已就发现的23个公共MCP服务器问题通知相关维护者及服务平台。一家托管AI代理交换的公司已更新安全审查流程，以评估提交内容是否存在此类风险；另一家供应商则正在完全重新打包其MCP服务器。需注意，任何由Python或npm包运行程序启动，或标记为“最新”的MCP条目，均可能在下次会话时从公共注册中心解析新代码，即便服务器版本号保持不变。