vLLM SSRF：当白名单补丁带着同样的解析器缺陷

这是什么？

vLLM 的多模态模型可以从请求里提供的 URL 拉取图像、音频和视频。为了避免这一功能变成服务端请求伪造（SSRF）的原语，vLLM 会在拉取前把每个 URL 的主机名与一份白名单进行比对。两份公告表明，这道检查已被用同样的方式绕过了两次。

第一份是 CVE-2026-24779（GHSA-qh4c-xf7m-gxfc，发布于 2026 年 1 月 27 日，CVSS 7.1「高危」），是 MediaConnector 类中的 SSRF：主机名用一个 URL 解析器校验，却用另一个解析器去拉取。第二份是 CVE-2026-25960（GHSA-v359-jj2v-j536，发布于 2026 年 3 月 9 日，CVSS 5.4「中危」），是对该补丁的绕过：补丁把校验改用了新的解析器，但异步拉取路径仍在使用第三个解析器。同一类缺陷，被修复本身重新打开。二者都属于 CWE-918，整条链路在 vLLM 0.17.0 中得到完整修复。

工作原理

这种模式叫作 解析器差异（parser differential）：用解析器 A 校验 URL，用解析器 B 发请求，并指望两者对目标主机的判断一致。一旦它们出现分歧，白名单守护的就是 HTTP 客户端实际上从不会去连接的那个主机名。

在最初的 MediaConnector 缺陷里，校验用的是 Python 的 urllib（urlparse），而拉取走的是 requests（底层依赖 urllib3）。两者遵循不同的 URL 语法——一个更接近 RFC 3986，另一个更接近 WHATWG 标准——对反斜杠的处理并不一致，这就足以让另一个主机混过白名单。

补丁（PR #32746）把校验统一到了 urllib3.util.parse_url()。但异步拉取路径，即 vllm/connections.py 中的 load_from_url_async，是用 aiohttp 发请求的，而 aiohttp 内部用 yarl 库解析 URL。公告精确地记录了这一分歧：

输入 URL: https://httpbin.org\@evil.com/

urllib3.parse_url()  -> host = httpbin.org   (把 "\" 编码为 %5C，把 "\@evil.com/" 当作路径)
yarl (经由 aiohttp)  -> host = evil.com      (把 "httpbin.org\" 当作 userinfo，"@" 当作分隔符)

于是校验器看到的是 httpbin.org 并放行请求；aiohttp 随后却连到了 evil.com。白名单通过了，请求却去了别处。这里不需要任何花哨的 payload——规范的示例 URL 就写在公开公告里，而其背后的技术（解析器之间在反斜杠与 @/userinfo 上的混淆）是一类早已为人所知的 SSRF 过滤绕过，并非新型攻击。

为什么重要

推理服务器上的 SSRF 远不止是一次向外的 curl。vLLM 经常部署在集群内部——公告点名了 llm-d 式的拓扑——在那里，Pod 位于一个可信的内网中，且没有出站过滤。由请求控制的拉取于是可以触及 Pod 能看到的内部服务：元数据端点、相邻 Pod、管理 API 和数据库。第一份公告指出，攻击者可以打到一个内部管理端点并上报伪造的指标（例如错误的 KV 缓存状态），从而扰乱整个服务集群。

更宽泛的教训正是这两个 CVE 通过重复给出的。先校验再拉取，只有在两次都由同一个组件解析主机时才是安全的。 把 urllib→urllib3 换成 urllib3→yarl，修掉了一处具体的差异，又引入了另一处，因为「解析两次并假定它们一致」这一架构原封未动。白名单绕过很少源于某一条写错的正则，而是源于两段代码对一个字符串的含义产生了分歧。

防御

如果你在使用 vLLM 的多模态 URL 拉取功能，请升级到 0.17.0 或更高版本，它修复了异步路径（PR #34743）。

除了打补丁，还应把 URL 拉取功能当成它本来的样子：一个 SSRF 汇聚点。如果你的部署并不需要，就关闭远程媒体拉取，改为给模型喂入预先下载好的字节。在确实需要拉取的场景下，把边界设在网络层而不是字符串解析层：禁止推理 Pod 向内部网段以及云元数据 IP 出站，这样即使白名单被绕过也触及不到任何有价值的东西。

针对「解析器差异」这一类问题，不要校验 URL 的某一种表示形式，却把原始字符串交给另一个客户端。只解析一次，把主机解析成 IP，用你的策略校验该 IP，然后连接到这个被锁定的地址——让你批准的主机就是你连接的主机。对媒体拉取屏蔽重定向（vLLM 通过 VLLM_MEDIA_URL_ALLOW_REDIRECTS 控制这一行为），因为 30x 响应是又一种在检查之后改变真实目的地的手段。

状态

项目	详情
CVE-2026-24779（MediaConnector SSRF）	发布于 2026-01-27 · CVSS 7.1 高危 · 修复 PR #32746
CVE-2026-25960（SSRF 防护绕过）	发布于 2026-03-09 · CVSS 5.4 中危 · 影响 vLLM ≥ 0.15.1 · 修复 PR #34743
修复版本	vLLM 0.17.0
弱点	CWE-918（服务端请求伪造）