2026年9月8日，我们收到了来自 Knostic 的安全研究员 Gadi Evron 的警报，指出 GLM-5.3 Workers AI 模型（ @cf/zai-org/glm-5.3 ）在2026年8月27日开始存在租户隔离问题。我们已经修复了此问题，并于9月9日恢复了模型。我们已确认其他在 Workers AI 上托管的模型未受影响。在2026年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 项目中提交了一份报告，指出发送到 @cf/zai-org/glm-5.3 的非常长的提示有时返回属于其他用户会话的文本。Cloudflare 于第二天早上重现了该问题，并在声明事件后的40分钟内将模型下线。随后，我们部署了修正的配置和修补过的推理引擎，并在同一天恢复了服务。这份关于跨请求 KV 缓存暴露的具体报告是由于两个重叠问题造成的。第一个是 Cloudflare 使用的开源推理引擎 SGLang 的配置错误。我们以 1,048,576 个标记的上下文窗口部署了 GLM 5.3，但我们的预填充 GPU 上的 KV 缓存池只有 681,280 个标记的空间。我们在启动之前就意识到了这种不匹配。我们原本预期引擎会对任何无法处理的提示返回错误，而我们的长上下文测试返回成功响应，因此我们并不认为这是一个问题。第二个是 SGLang 在分散的预填充/解码模式下处理过长请求时的一个漏洞。一个不适合池的提示被内部标记为拒绝，并用一个标记的占位符替换，但预填充并没有终止请求并返回客户端错误，而是为占位符提示生成了 KV 缓存，并将其转移到解码节点。解码节点收到“传输完成”消息，并假定预填充用此请求的完整提示覆盖了之前请求的 KV 缓存，但实际上保留了大部分先前状态。解码节点随后产生了响应，同时处理仍持有早期请求数据的过时缓存页面。因此，对于超过 681,280 个标记的提示的响应可能包含其他用户的 GLM 5.3 会话数据。立即修复 在停用该模型后，我们采取了以下措施，以在恢复公众访问之前纠正此漏洞：为了修复我们的配置，我们使池能够容纳完整上下文。我们调整了 GLM 5.3 的配置，使其与 GLM 5.2 的配置匹配，从而释放了足够的 GPU 内存，使得预填充 KV 池现在能容纳大约 204 万个标记，大约是 1,048,576个标记上下文长度的两倍。适合上下文窗口的提示现在始终适合池，因此有效请求不会到达拒绝路径。仅这一点就防止了漏洞被利用。为了修复引擎，我们还使拒绝路径变得安全。仅依赖池大小是脆弱的：对量化、张量并行性、CUDA 图形大小或未来模型版本的任何更改都会以容易被忽视的方式改变池大小。此外，预填充调度器可能会拒绝请求并触发相同漏洞的其他情况。为防止这种情况，我们还修补了引擎，使得携带待处理拒绝的请求在分散接纳队列中用其原始错误被退回，而在任何引导、分配或 KV 转移发生之前。我们将其作为 #38704 提交了上游，解码节点还验证传输的标记数量是否与其保留的数量匹配。该修复已在 #36988 的 SGLang 主分支中合并，9月6日为相关的失败路径，尚未发布。维护者还合并了 #38935 ，该请求更早地拒绝这些请求，遵循了我们的做法。