Cloudflare 的 KV 缓存隔离失效：GLM-5.3 事件

2026 年 10 月 26 日，Cloudflare 公布了一起安全事件的细节。2026 年 8 月 27 日至 9 月 9 日期间，Workers AI 上的 GLM-5.3 模型向部分客户返回的响应中，包含了来自其他用户请求的数据。事件共涉及 155 条响应，全部由超过 681,280 个 token 的提示生成。据 Cloudflare 称，Workers AI 的其他模型均未受影响。泄露有两个原因。一是模型的上下文窗口（1,048,576 个 token）与 prefill GPU 上 KV 缓存池的容量（681,280 个 token）之间存在配置不匹配。Cloudflare 在上线前就知道这一点，但没有料到会引发问题。二是开源推理引擎 SGLang 中的一个错误。

根据该公司的复盘，当提示超出 KV 缓存上限时，处于分离（disaggregated）模式的 SGLang 会把请求标记为“已拒绝”，并用占位符替换，却没有中止处理流程。准入队列只检查执行是否完成，不检查请求是否已被拒绝。于是 decode 节点读取了仍保存着先前提示数据的内存页，并向客户端返回 HTTP 200，而不是错误。早在 2026 年 7 月 6 日，SGLang 的代码仓库中就已有人以 issue #30233 报告过类似问题。此外，据 Unite.AI 依据官方报告转述，Cloudflare 上线前的检查覆盖了 HTTP 响应码和长上下文性能，但没有检查模型最终输出是否正确。

2026 年 9 月 8 日，Knostic 的安全研究员 Gadi Evron 通过 HackerOne 报告了这一问题。9 月 9 日（UTC），Cloudflare 用两个不同账户复现问题后，于 13:22 宣布进入事件响应。14:00 模型被设为私有，14:35 查明原因。在把 prefill 的 KV 缓存池扩大到约 204 万个 token 之后，模型于 19:40 重新公开。这大约是上下文窗口的两倍，与 GLM 5.2 的配置一致。SGLang 的修复会在任何 KV 传输之前，带着原始错误直接丢弃被拒绝的请求。该修复已提交上游（#38704），从 SGLang v0.5.20 起包含在内。报告的发布与 SGLang 的维护者（RadixArk）进行了协调。Cloudflare 建议 SGLang 用户升级到 v0.5.22 或更高版本，并在每个节点上核对 KV 池大小与上下文长度。不过，仍有不少疑问没有答案。Cloudflare 在报告中表示没有发现蓄意利用的证据（“We found no evidence of deliberate exploitation”），但这是未经第三方核实的内部评估。Cloudflare 没有说明有多少客户受影响，只称数量很少。它也没有说明这 155 条响应中具体暴露了哪类数据，以及是否、又如何通知了受影响的客户。Evron 的研究报告尚未发布。

把 prefill 和 decode 拆到不同的基础设施上，可以承担长上下文的成本，但安全边界也随之转移到共享 GPU 内存的完整性上。当资源优化和性能测试先于输出正确性检查时，只要有一个错误状态没被拦住，效率就可能变成一次意外的隔离失效。 — Olya