服务层就是攻击面：vLLM 与 SGLang 中的并发缺陷

摘要 大多数 LLM 安全测试针对的是模型本身：越狱、提示注入、幻觉。但越来越多的研究指出，服务框架——负责把请求批处理、在租户之间共享 KV 缓存、并调度 GPU 时间的引擎——本身就是一道安全边界，而且更易被突破。2026 年 5 月发表的论文 Continuous Discovery of Vulnerabilities in LLM Serving Systems with Fuzzing（arXiv 2605.11202）提出了 GRIEF，一个把带时间戳的并发请求轨迹作为变异对象的灰盒模糊测试器。在对 vLLM 与 SGLang 各 8 小时的初步测试中，它暴露出 15 个漏洞，其中 10 个已获维护者确认，包含 2 个已分配的 CVE——全部由完全合法、只有在彼此重叠时才变得危险的请求触发。

这是什么？

像 vLLM 或 SGLang 这样的现代推理引擎，并不是模型外面一层薄封装。为达到 GPU 利用率目标，它会运行连续批处理、共享的分页 KV 缓存、前缀共享、推测解码、LoRA 适配器复用以及多租户调度器。这一切都制造出在不同用户的请求之间共享的可变状态。标准测试从不检验这一点：模型安全评测检查单条回答是否安全，API 测试检查单条请求是否被正确处理，传统模糊测试器则寻找畸形字节导致的崩溃。没有任何一种会去探测：当数十个各自合法的请求在真实并发下争夺同一缓存与同一调度器时，会发生什么。

GRIEF（arXiv 2605.11202）是系统性地对这一攻击面做模糊测试的首次尝试。其威胁模型刻意设得很弱：一个无特权的 API 客户端，通过文档化的接口发送格式良好的请求——没有畸形流量、没有特权访问、没有主机同驻。其结果是首次以实证表明，服务栈是「一片独立且测试不足的漏洞面」。

工作原理

关键思路在于输入抽象。GRIEF 不去变异字节串或单个提示，而是把带时间戳的请求轨迹作为模糊测试单元：一串带时间戳的客户端事件，记录请求何时重叠、携带何种形状，以及哪些请求应共享同一语义提示身份。模糊测试器对共批、前缀缓存复用、适配器共调度、取消时机与调度器压力进行变异，再用轻量级判别器——延迟异常、KV 缓存遥测、跨运行输出对比——标记可疑的运行。由于 LLM 服务嘈杂且具非确定性，任何可疑情形都会进入受控重放阶段，借助多数表决与 token 对数概率检查，把真实缺陷与调度抖动区分开。

研究结果归为三类影响（论文表 1）：

失效类别                     总数  vLLM  SGLang  已确认  代表性影响
状态损坏 / 隔离失效              7     5      2       7     跨请求输出污染
性能病态                        4     2      2       2     「吵闹邻居」式拒绝服务
崩溃 / 存活性                   2     1      1       1     调度进程可用性丧失

在隔离类别中，一次并发负载导致某请求复用了另一请求过期的 KV 缓存状态，污染了受害者的输出——这是一次没有崩溃、日志中也无报错的隔离突破。在性能类别中，一条合法但被攻击者精心构造的请求把自身成本转嫁到了同调度的用户身上，推高首 token 延迟、把有效吞吐压到近乎为零。在存活性类别中，一批合法的 LoRA 适配器请求违反了调度器不变量并中止了服务进程——由于崩溃相对触发点存在延迟，日志在故障前仍显示正常的 prefill 与成功响应。

这一性能病态类别，正是 2026 年 2 月另一篇论文 Rethinking Latency Denial-of-Service: Attacking the LLM Serving Framework, Not the Model（arXiv 2602.07878）所形式化的 Fill and Squeeze 策略：Fill 耗尽全局 KV 缓存以诱发队头阻塞，Squeeze 迫使调度器反复抢占。作者报告，相比以往模型层面的减速攻击，首 token 时间最高可被拖慢 20–280 倍，而攻击成本低 30–40%——其手段是攻击 FCFS 调度器的状态，而非模型。

为什么重要

有两个特性让情况更糟。其一，这些失效无一需要畸形输入或显式报错——它们是无声的。输出被另一用户 KV 缓存状态污染的租户，得不到任何出错信号；只盯着「仅崩溃」仪表盘的运维者，看到的是一台健康的服务器。GRIEF 作者引用的实证研究估计，超过 35% 的推理引擎缺陷表现为非崩溃异常。其二，攻击者门槛很低：共享多租户接口上一个普通的付费 API 用户，只要调整请求节奏，就能拖垮或污染其他租户。对任何运行共享 vLLM 或 SGLang 集群的人——内部平台团队、推理即服务提供商——这都是一个跨租户的机密性与可用性问题，而非关于模型质量的脚注。它直接对应 OWASP LLM Top 10 的 Unbounded Consumption（无界消耗）以及经典的租户隔离要求。

防御

采取行动无需任何 payload；缓解措施是架构层面的。

• 测试并发，而不仅是请求。 为任何自托管引擎在 CI 中加入服务层模糊测试或并发轨迹重放（即 GRIEF 的方法）。按请求的正确性测试抓不到这些缺陷。
• 在缓存中强制租户隔离。 按租户对 KV 缓存与前缀共享池进行分区或加键，使跨请求复用无法跨越信任边界；在机密性重要的场景禁用跨租户前缀共享。
• 让调度器公平且有界。 用公平份额或优先级调度取代朴素的 FCFS，对每租户的 KV 缓存占用与在途 token 数设上限，并施加准入控制，避免单个客户端独占 GPU 显存。近期的调度研究（如队头阻塞缓解）正是针对 Fill and Squeeze 模式。
• 配额与限速作为财务底线。 按租户的 token 速率与请求速率限制，是抵御「吵闹邻居」与钱包拒绝服务效应的第一道防线。
• 观测正确的信号。 「仅崩溃」式监控在这里是盲的。跟踪每租户的 TTFT/TPOT 分布、KV 缓存命中/逐出遥测以及抢占计数；把持续的跨租户延迟分化当作安全事件处理。
• 及时打补丁。 GRIEF 的两个 CVE 已获 vLLM/SGLang 维护者确认——保持引擎更新并关注其安全公告。

状态

GRIEF 于 2026 年 5 月发表（arXiv 2605.11202）；在以 Qwen-2.5-0.5B-Instruct 测试的 vLLM 与 SGLang 上，报告 15 项发现，其中 10 项获开发者确认、2 项已分配 CVE，另有 CVE 申请待处理。互补的延迟拒绝服务分析（arXiv 2602.07878）发表于 2026 年 2 月。GRIEF 作者遵循负责任披露，刻意不公开完整的利用清单；本文同样只描述失效的类别及其防御，而非复现步骤。无论某个补丁如何，核心结论都是持久的：对于自托管 LLM，推理引擎的并发、缓存与调度逻辑是一道一等的安全边界，需要专门的测试。