系统:运行中
← 返回所有攻击
AGENTS MEDIUM NEW

VIPER-MCP:40,000 个 MCP 服务器中的污点型漏洞带来 67 个 CVE

2026 年 5 月 20 日的一篇 arXiv 论文审计了 39,884 个开源 MCP 服务器仓库,端到端确认了 106 个零日漏洞,并已分配 67 个 CVE 编号。重点在于这一模式:不可信的智能体输入抵达 shell、网络与文件系统的 sink。

2026-06-05 // 6 min affects: mcp-protocol, mcp-servers, llm-agents

What is this?

2026 年 5 月 20 日,一支团队(Pengyu Sun、Qishu Jin、Enhao Huang、Zifeng Kang、Xin Liu、Dakun Shen 与 Song Li)在 arXiv(cs.CR,2605.21392)发布了 VIPER-MCP。这是一个针对 Model Context Protocol(MCP)服务器的自动化漏洞审计框架——这些小程序把工具(shell 命令、HTTP 请求、文件访问、数据库查询)暴露给 LLM 智能体。

引人注目的数字:在对 39,884 个开源 MCP 服务器仓库的扫描中,VIPER-MCP 发现了 106 个零日漏洞,并以端到端的利用轨迹逐一确认,迄今已分配 67 个 CVE 编号。作者表示,所有确认的发现都已负责任地披露给受影响的开发者。我们报道此事并非因为某个具体漏洞前所未见——它们都是经典的注入类缺陷——而是因为该测量量化了 MCP 生态系统自诞生以来一直背负的一种模式:智能体的自然语言输入未经清洗便抵达敏感 sink。

How it works

“污点型”漏洞是一条路径:攻击者可控的输入()在中途缺乏充分校验的情况下抵达危险操作(sink)。在 MCP 服务器中,源是模型填入的工具参数;sink 是工具处理函数对它所做的事。当该处理函数调用 shell、打开 socket、拼接文件路径或组装查询时,一个不受约束的参数就变成命令注入、SSRF、目录遍历或 SQL 注入——而由于 MCP 工具以服务器权限运行,最终状态往往是远程代码执行。这与 Akamai 的 MCP 后端发现属于同一类,也是微软记录的当提示词变成 shell 时所跨越的同一道边界。

VIPER-MCP 的贡献在于让这一切可在规模上审计而不被误报淹没。它结合两个阶段,此处只在方法层面描述,不涉及 payload:

阶段                  作用
--------------------  ----------------------------------------------------------
两遍静态扫描          标准污点分析标记候选的 源->sink 路径,随后"anchor-query"遍
                      加入函数级结构,使文件级告警解析到具体的 MCP 工具处理函数,
                      并生成具体的调用链。
动态确认              一个由反馈驱动的循环将自然语言提示词朝被标记的 sink 精化。
                      两个变异器独立运行:一个纠正工具选择漂移,一个加深参数渗透;
                      由 fitness 打分的种子引导搜索。
判定                  仅当端到端轨迹确实抵达 sink 时才报告一条路径——因此"发现"
                      是经确认的利用,而非未经验证的告警。

方法论意义在于:以往的 MCP 扫描器要么产生无人能分诊的静态告警,要么依赖固定的 payload 模板,从而遗漏那些需要特定参数形态或多步路径的漏洞。相对两个现有基线,作者报告的误报率为 4.6%、漏报率为 7.7%。此处不复现任何利用提示词;权威参考是该论文与已分配的 CVE 记录。

Why it matters

MCP 服务器层如今已是一条庞大且快速增长的软件供应链,多数团队是安装它而非自行编写。2026 年 6 月的测量为这种暴露给出了硬数字:据 Adversa 的 MCP 综述,Censys 统计到 12,520 个可从互联网访问的 MCP 服务(多数未认证),另一项测量研究发现约 40% 的远程服务器在没有任何认证的情况下暴露其工具。VIPER-MCP 补上了代码质量这一维度:其中相当一部分服务器的工具处理函数还携带可利用的污点型缺陷。

由此产生两点后果。其一,一个有漏洞的 MCP 服务器把提示词注入变成 RCE。如果攻击者能影响智能体读取的内容——网页、文档、评论——就能驱使它以恶意参数调用有缺陷的工具。智能体是投递载体;服务器漏洞才是 payload。其二,40,000 个仓库中有 67 个 CVE,意味着你的依赖图几乎必然包含其中一些。与单条公告不同,这是一类需要清扫的问题,而非一次性修补的一行。

Defenses

这些修复并不炫目、且众所周知——差距在于 MCP 服务器代码常常跳过它们。

  1. 把每个工具参数都当作不可信输入。 模型不是可信调用方;其参数可能经由间接注入被攻击者影响。在处理函数边界、在值抵达任何 sink 之前,校验类型、长度与允许的字符集。

  2. 消除危险 sink。 避免 shell=True / 字符串拼接命令(应传入参数向量),对每条数据库查询使用参数化,将文件路径解析并限定到白名单根目录,并把出站请求限制到目的地白名单以阻断 SSRF。绝不要把工具参数传给 eval/exec

  3. 以最小权限与隔离运行服务器。 缩小影响范围:专用低权限用户、沙箱或容器、无环境云凭证、网络出口过滤。受限的 RCE 是一起事件;不受限的则是一次入侵。

  4. 为远程服务器加认证并撤下暴露。 在每个远程 MCP 服务器前置认证,并把未认证的从公网撤下——这是影响最大的一步,也是暴露统计显示多数运营者仍未做到的一步。

  5. 在信任第三方服务器之前先审计。 静态污点扫描(VIPER-MCP 所自动化的)加上对你启动时加载哪些服务器的审查。检查这 67 个已分配 CVE 是否触及你的依赖,并跟进上游补丁。

  6. 加入信任与准入层。 将上述做法与诸如经证明的工具服务器准入(签名许可、默认拒绝白名单)等提案结合,并以 NSA 的 MCP 安全设计考量作为基线。

Status

项目参考日期备注
VIPER-MCP 论文arXiv:2605.21392 (cs.CR)2026-05-20面向 MCP 服务器的静态 + 动态审计框架
扫描范围论文2026-05-2039,884 个开源 MCP 服务器仓库
发现论文2026-05-20确认 106 个零日,迄今分配 67 个 CVE
披露论文2026-05-20负责任披露;协调 CVE 分配
生态暴露Adversa / Censys2026-06-0412,520 个互联网暴露的 MCP 服务,约 40% 的远程服务器未认证

正确的定性不是”MCP 坏了”——而是 MCP 服务器是带着普通注入漏洞的普通软件,却以非同寻常的权限部署、且常常没有认证。前置的智能体只是让攻击者更容易抵达”源”。清扫你的服务器以排查已披露的 CVE,消除 sink,并在一切能执行命令的东西前面加上认证与隔离。

Sources