vLLM 结构化输出：一条正则即可冻结推理 worker

这是什么？

2026 年 7 月 6 日，面向 vLLM 发布了一则安全公告。vLLM 是部署最广泛的大语言模型开源推理与服务引擎之一。该缺陷是结构化输出功能中的一个拒绝服务问题：允许调用方将模型输出约束为符合某个正则表达式的 API 参数，会把用户提供的模式直接交给语法编译器，没有任何时间或复杂度上限。一次携带恶意模式的请求即可无限期地占住一个推理 worker。该问题被归类为正则表达式复杂度低效缺陷（CWE-1333，即通常所说的 ReDoS），影响 0.24.0 之前的所有版本，并已在该版本修复。

这既不是提示词层面的攻击，也不是模型越狱，而是一个经典的服务层可用性缺陷，只不过恰好位于 LLM 特有的功能之中——正是随着团队把受约束解码接入生产 API 而不断扩大的那类攻击面。

工作原理

结构化输出通过在每个 token 上约束解码器，让应用能够强制模型输出符合某种模式（JSON、语法或原始正则表达式）的文本。为此，所选正则必须被编译成采样器会查询的状态机。

在受影响的版本中，这一编译步骤没有任何防护。在 xgrammar 后端，模式会直接抵达正则编译器；在 outlines 后端，校验会拒绝诸如环视（lookaround）和反向引用（backreference）等结构性写法，却不做任何复杂度分析——因此由嵌套量词构造的模式能通过所有检查，随后引发爆炸。某些正则形态会让编译器探索指数级数量的状态，于是一个短小、看似无害的字符串就转化为几乎无上限的计算量。由于该请求经网络无需认证即被接受，且编译发生在任何生成之前，一次构造的调用便足以挂起 worker，并使路由到它的所有正常请求陷入饥饿。报告的影响仅涉及可用性——没有代码执行，也没有数据泄露——攻击向量为网络，且无需任何权限。我们在此有意不复现任何触发模式；重点是机制本身，而非可直接使用的载荷。

为何重要

vLLM 处于大量自托管与企业级 LLM 技术栈的核心，通常位于一个信任其调用方的内部网关之后。结构化输出是让模型响应可被程序解析的常见方式，因此这个易受攻击的参数并非偏僻角落，而恰恰是在自动化、高吞吐流水线中被频繁使用的功能——而未被察觉的挂起在这类场景中危害最大。在共享的多租户部署中，任何一个能设置正则的租户都可能拖垮同一 worker 池上其他所有租户的服务；而一个暴露在外的端点，会把一行请求变成低成本的宕机。这是一个有益的提醒：LLM 服务层在承担模型特有风险之外，也继承了普通 Web 服务的一切常规风险。同一引擎中相邻的可用性缺陷——从音频上传导致的内存耗尽问题到更广义的服务层攻击面——都指向同一条教训。

防御

将 vLLM 升级到 0.24.0 或更高版本。这是主要且完整的修复：补丁加入了有界的编译步骤，使得恶意模式会快速失败，而不再挂起。公告还记录了一个编译超时控制项（VLLM_REGEX_COMPILATION_TIMEOUT_S，默认五秒），它会抛出错误而非无限期阻塞，为你提供一个可记录与告警的信号。

除打补丁外，请将正则参数视为不可信输入。如果你的应用并不需要调用方提供正则，就禁用或在代码中固定结构化输出的模式，而不要让用户值直接通过。若必须接受，请在编译前校验模式的长度与复杂度，并拒绝嵌套量词。不要直接暴露推理端点：要求认证，并按调用方施加速率限制，使单个客户端无法独占 worker。

在检测方面，留意在编译期间停止响应或 CPU 飙升的推理 worker，并在修复到位后监控编译超时错误。常用的系统工具——用 top/htop 定位卡住的 worker，对可疑进程做跟踪以判断其是否卡在正则编译中——都能揭示正在进行的尝试。

状态

项目	详情
受影响	vLLM，0.24.0 之前的所有版本
修复版本	vLLM 0.24.0（PR #45118）
缺陷类型	CWE-1333，正则表达式复杂度低效（ReDoS）
影响	拒绝服务——仅可用性；无需认证、网络、无需权限
严重度	CVSS 4.0 8.7（高，CNA）/ CVSS 3.1 7.5（高，NVD）；本站评级：中
参考	CVE-2026-55574（发布于 2026-07-06）；公告 GHSA-rwxx-mrjm-wc2m