据 NVD 与多个漏洞追踪站披露，vLLM 在 0.30.0 之前存在一条被编号为 CVE-2026-105754 的多模态预处理缺陷。问题出在 /inference/v1/generate 这个端点：服务端信任了来自请求体的 kwargs_data 字段、features.mm_hashes 里的缓存标识，以及 features.mm_placeholders 里的占位区间，还允许在传输层直接选定多模态字段处理器，却没有把这些东西重新绑定到当前激活模型的渲染契约上。这一串信任默认，被合成一个可以跨请求污染共享状态的攻击面。
伪造一个网格几何，为什么能直接打死共享 EngineCore？
vLLM 的多模态后端要把一张图或一段视频切成若干 patch 网格，再交给视觉编码器算一次、缓存起来，后面文本 token 直接引用这个编码器缓存。问题在于，这个网格几何（grid geometry）和占位长度是由请求方说了算的。攻击者传一个类型错误、或者一个非正的占位长度，共享的 EngineCore 进程会直接崩溃。注意是「共享」二字：EngineCore 是整个服务端所有请求共用的那个推理核心，一个畸形请求打崩它，等于让所有在线用户一起吃 DoS。这不是把自己的容器搞挂，是把同台服务上别人的会话一起端掉。
知道受害者的内容哈希，能干什么更阴的事？
更值得警惕的是缓存投毒这一段。多模态预处理为了省算力，会对输入内容算一个哈希，内容没变就直接复用上一次的编码器结果。一旦攻击者知道、或者能诱导出受害者的内容哈希，他就可以伪造一个相同哈希的条目写进缓存，让受害者下一次请求取回的是被污染过的编码器状态。官方描述里还提到，被丢弃的稀疏占位掩码会改变重放时的传输语义。换句话说，这不是简单的读文件，而是在多租户共享推理服务里，把别人缓存里的「视觉理解结果」换成自己想要的版本。对一个把 vLLM 当多租户网关、开了前缀与编码器缓存的部署来说，这条链的危害远超普通崩溃。
0.30.0 到底补了哪几刀？
官方在 0.30.0 里把这些字段全部收回到服务端校验：网格几何与字段类型强制对齐激活模型的渲染契约，占位长度必须为正，缓存哈希与请求做绑定，多模态处理器不再由传输层任意指定。顺带一提，这不是孤例——同一波披露里还有 CVE-2026-105752、PYSEC-2026-4198 等若干条，都是 vLLM 在多模态与缓存边界上的信任问题。跑多租户、开了缓存、又把 0.30.0 之前版本挂在公网的团队，现在最该做的一件事就是升版本、并把 /inference 这一类内部端点收敛到内网。
去论坛讨论
前往 silicon-agi.com 论坛 参与讨论