一个工程师花三周挖出的221个漏洞，全怪同一行代码

安全研究员花了三周在vLLM里刨出221个漏洞，结果全是同一个根因——这种"批发式"漏洞模式，正在AI基础设施里批量复制。

「挖洞」变成了「批发」

研究员原本只想做个常规审计。三周后，CVE编号攒了221个。

诡异的是，这些漏洞分布在不同模块、不同功能里，表面看毫无关联。但溯源后发现，它们全部指向同一类代码缺陷：输入验证的系统性缺失。

不是221个独立错误，是1个错误模式×221个调用点。

这张图解释了AI基础设施的脆弱性

https://nimg.ws.126.net/?url=http%3A%2F%2Fdingyue.ws.126.net%2F2026%2F0416%2F3c361ec5j00tdkc08000kd000hs00c2p.jpg&thumbnail=660x2147483647&quality=80&type=jpg

vLLM作为大模型推理服务的核心引擎，每天要处理海量用户输入。它的架构特点是：前端接收提示词→中间层调度计算→后端对接GPU集群。

漏洞集中在「前端→中间层」的边界：用户输入被直接送进解析器，没有统一清洗层。每个功能模块各自做验证，有的做、有的漏、有的做一半。

结果就是：同样的攻击载荷，换个子路径就能绕过。

为什么AI系统特别容易「批发漏洞」

传统软件的开发周期里，输入验证是基础设施课。但AI工程的速度压力改变了优先级——「能跑通提示词」优先于「防住恶意提示词」。

vLLM的代码库增长极快：2023年还是个学术项目，2024年已成为生产标配。功能迭代速度超过了安全审计的覆盖能力。

更麻烦的是，AI系统的输入维度爆炸。文本、图像、音频、结构化数据，每种格式都要验证，每种都有独特的攻击面。

221个CVE背后的行业信号

研究员在报告中提到：「这不是vLLM独有的问题，我检查过的AI框架里，超过60%存在类似的验证层缺失。」

Langflow的CVE-2026-33017（未经认证的远程代码执行）也是同一路径：公开接口直接暴露内部执行环境，没有中间隔离层。

AI基础设施正在重复2010年代云计算的安全弯路——先堆功能，后补漏洞。但大模型的攻击面比虚拟机复杂一个数量级。

221个漏洞，3周发现，1个根因。这个数字组合说明：AI工程的安全债，已经到了批量清算的阶段。