GLM-5.3 Workers AI 模型中的交叉请求 KV 缓存暴露（155 个响应）

2026 年 9 月 8 日，Knostic 的安全研究员 Gadi Evron 向我们发出警报，称自 2026 年 8 月 27 日起影响 GLM-5.3 Workers AI 模型 (@cf/zai-org/glm-5.3) 的租户隔离问题。我们已修复该问题，并于 9 月 9 日恢复了该模型。我们已确认 Workers AI 上托管的其他模型没有受到影响。 8 月 27 日至 9 月 9 日期间，少数使用 GLM 5.3 Workers AI 模型的客户收到了响应，其中包含其他客户在他们之前不久向同一模型发出的请求的数据。总共有 155 个响应受到影响，所有提示都超过 681,280 个令牌。在排除我们自己和研究人员的测试后，我们确定的请求在时间和数量上与普通的长上下文使用一致，而不是与某人重复利用该错误一致。我们没有发现蓄意剥削的证据。今天，我们将这份报告与我们使用的开源推理引擎 SGLang 的帖子一起发布，作为协调披露。这篇文章描述了导致此问题的错误、我们的响应时间表以及我们对生产 SGLang 部署进行的后续强化。我们还详细介绍了我们与 SGLang 上游维护者的持续努力，以解决此错误和类似错误。发生了什么 GLM 是 Z.ai 的文本生成模型，专为代理编码工作流程而构建；它是 Workers AI 提供的众多模型之一。 Gadi Evron 于 9 月 8 日通过我们的 HackerOne 程序提交了一份报告，指出发送到 Workers AI 上的 @cf/zai-org/glm-5.3 的很长的提示有时会返回属于其他用户会话的文本。 Cloudflare 第二天早上重现了该问题，并在宣布事​​件后 40 分钟内将该模型下线。然后，我们部署了更正的配置和修补的推理引擎，并在同一天恢复了服务。这个跨请求 KV 缓存暴露的具体报告是两个重叠问题的结果。第一个是 Cloudflare 使用的开源推理引擎 SGLang 的配置错误。我们部署了具有 1,048,576 个令牌上下文窗口的 GLM 5.3，但预填充 GPU 上的 KV 缓存池只有 681,280 个令牌的空间。我们在发布之前就意识到了这种不匹配。我们预计引擎会针对其无法处理的任何提示返回错误，并且我们的长上下文测试返回成功的响应，因此我们认为这不是一个问题。第二个是 SGLang 如何在分解预填充/解码模式下处理生成的超长请求的错误。不适合池的提示在内部被标记为拒绝并替换为单令牌占位符，但 prefill 没有中止请求并返回客户端错误，而是为占位符提示生成 KV 缓存并将其传输到解码节点。解码节点收到“传输完成”消息，并假设预填充使用此请求的完整提示覆盖了先前请求的 KV 缓存，而实际上它保留了先前状态的大部分完好无损。解码节点随后生成响应，同时关注仍保存来自早期请求的数据的陈旧缓存页面。因此，对超过 681,280 个令牌的提示的响应可能包含来自其他用户的 GLM 5.3 会话的数据。立即修复 禁用模型后，我们在恢复公共访问之前采取了以下操作来纠正此漏洞： 为了修复我们的配置，我们使池保存完整的上下文。我们调整了 GLM 5.3 配置以匹配 GLM 5.2 配置，这释放了足够的 GPU 内存，使得预填充 KV 池现在可容纳约 204 万个令牌，大约是 1,048,576 个令牌上下文长度的两倍。现在，适合上下文窗口的提示始终适合池，因此有效请求永远不会到达拒绝路径。仅此一点就可以防止该错误被执行。为了修复引擎，我们还确保了拒绝路径的安全。单独依赖池大小是脆弱的：对量化、张量并行性、CUDA 图大小或未来模型版本的任何更改都会以一种很容易被忽略的方式改变池大小。此外，可能存在预填充调度程序可以拒绝请求并触发相同错误的其他情况。为了防止这种情况，我们还修补了引擎，以便在任何引导、分配或 KV 传输发生之前，携带待处理拒绝的请求会在分解准入队列中退出，并带有其原始错误。我们将此上游建议为 #38704 ，它还让解码节点验证传输的令牌数量与其保留的数量相匹配。该修复已在 #36988 中的 SGLang main 上进行，并于 9 月 6 日合并以解决相关故障路径，但尚未发布。维护者还合并了#38935，它按照我们的方法早些时候拒绝了这些请求。在恢复之前，我们根据研究人员的复制脚本和我们自己的金丝雀标记测试验证了这两项更改