Cloudflare 披露 GLM-5.3 跨租户会话泄漏 155 条响应

Cloudflare 于 2026 年 10 月 26 日发布事故报告，披露其 Workers AI 平台上 GLM-5.3 模型存在跨请求 KV 缓存暴露问题，其中 155 条针对超长提示词的响应包含了其他客户会话的数据。

Knostic 的安全研究员 Gadi Evron 于 2026 年 9 月 8 日通过该公司的 HackerOne 项目向 Cloudflare 报告了这一租户隔离问题。该暴露问题自 2026 年 8 月 27 日起影响以 @cf/zai-org/glm-5.3 提供的该模型，而这一天正是 GLM 5.3 在 Workers AI 上线的日子。Cloudflare 修复了该问题并于 2026 年 9 月 9 日恢复该模型，并表示已确认 Workers AI 上托管的其它模型均未受影响。

全部 155 条受影响响应均对应长度超过 681,280 个 token 的提示词。Cloudflare 表示，在排除其自身测试和研究人员的请求后，其识别出的请求在时间分布和数量上与普通的长上下文使用相符，而非对漏洞的反复利用，并且未发现任何故意利用的证据。

GLM 是 Z.ai 推出的文本生成模型，专为智能体编程工作流构建，是 Workers AI 提供的众多模型之一。Cloudflare 使用开源推理引擎 SGLang 以分离式配置运行 GLM 5.3：prefill GPU 处理提示词并生成其 KV 缓存，然后通过 Mooncake 以远程直接内存访问（RDMA）方式将该缓存移交给生成响应的 decode GPU。KV 缓存是一个由固定大小页面组成的共享池；页面在请求之间不会清零，因此引擎负责跟踪每个页面的归属。

报告将此次暴露归因于两个问题。第一个是配置错误：Cloudflare 部署 GLM 5.3 时使用了 1,048,576 个 token 的上下文窗口，但其 prefill GPU 上的 KV 缓存池仅能容纳 681,280 个 token。Cloudflare 表示其在发布前已知道这一不匹配，但预期引擎会对任何无法处理的提示词返回错误，而其长上下文测试返回了成功响应，因此它并不认为该不匹配是个问题。该公司表示，其测试验证了长上下文下的 HTTP 响应码和引擎性能，但未验证模型输出和连贯性，并且现在会在任何分离式部署变更上线前直接核对 KV 池大小与上下文长度。

第二个是 SGLang 在分离式 prefill 和 decode 模式下处理超长请求时的缺陷。无法放入池中的提示词在内部被标记为已拒绝，并被替换为一个 token 的占位符，但 prefill 仍为该占位符生成了 KV 缓存，并发出传输完成的信号。随后 decode 节点在关注仍保留着先前请求数据的过期缓存页面的同时生成了响应，客户端收到的是 HTTP 200 响应而非 HTTP 400。

SGLang 团队在其自身的协同发布文章中表示，单节点拒绝路径会改为返回错误，因此该问题仅出现在分离式服务中。该缺陷已于 2026 年 7 月 6 日由另一名用户作为 issue #30233 报告给 SGLang，Cloudflare 表示其在调查过程中注意到了该问题。

事件响应与修复

Cloudflare 于 2026 年 9 月 9 日 08:00 UTC 开始核实该报告，并在其产品安全团队于 25 分钟内使用两个独立账户复现了泄漏后，于 13:22 宣布发生安全事件。它在 14:00 将 GLM 5.3 设为私有，在 14:35 确定根本原因，在 14:52 前将所有 prefill 节点滚动更新至修正后的配置，在 19:04 前使用 Cloudflare 编写的引擎补丁重建了完整部署，并在 19:40 恢复该模型的公开访问。Cloudflare 状态页面记录该 Workers AI 事件始于 2026 年 9 月 9 日美国东部时间上午 10:25，于美国东部时间上午 11:02 被确认，并于美国东部时间下午 4:09 解决。

配置修复与 GLM 5.2 的设置保持一致，释放了足够的 GPU 内存，使 prefill KV 池现在可容纳约 204 万个 token，约为 1,048,576 个 token 上下文长度的两倍，因此能放入上下文窗口的提示词总能放入池中。引擎补丁会在任何引导、分配或 KV 传输发生之前，在分离式准入队列中带着原始错误退回携带待处理拒绝的请求。Cloudflare 在恢复模型前，使用研究人员的复现脚本和其自身的金丝雀标记测试验证了这两项变更。

上游修复与持续工作

Cloudflare 将其修复作为 SGLang 拉取请求 #38704 提交至上游，维护者合并了 #38935，该合并遵循 Cloudflare 的方法在准入阶段拒绝受影响的请求；一项相关修复 #36988 已于 2026 年 9 月 6 日针对一条相关故障路径合并。该补丁随 SGLang v0.5.20 发布，后续版本为 2026 年 10 月 2 日发布的 v0.5.21 和 2026 年 10 月 19 日发布的 v0.5.22，Cloudflare 建议所有 SGLang 运维人员升级至 v0.5.22 或更高版本。SGLang 团队表示，v0.5.21 默认针对所有故障类型保护 Mooncake 和 NIXL 部署，MORI 部署需要 v0.5.22 中的构建，并且该修复系列未向后移植到更早的发布分支。

SGLang 团队报告称，在两块 H100 GPU 上进行的 21 次运行中，启用保护后的吞吐量差异在 ±2% 以内，每个 95% 置信区间均跨越零；在另一次于两块 H200 GPU 上进行的 16 次运行扫描中，测得默认启用延迟 KV 释放的成本为 −0.38%，置信区间为 −2.12% 至 +1.36%，其称该结果不显著。Cloudflare 于 2026 年 9 月 10 日在 RadixArk 与 SGLang 维护者会面，于 2026 年 9 月 11 日至 19 日期间对其所有生产 SGLang 部署实施了额外加固，涵盖准入修复、逐次传输校验和、中止确认保留以及默认启用延迟 KV 释放的上游合并于 2026 年 9 月 16 日至 10 月 12 日期间完成。

对于其他以分离模式运行 SGLang 的运维人员，Cloudflare 的报告建议：在对权重、量化、并行度或内存比例做出任何更改后，在每个 prefill 和 decode 节点上根据上下文长度测量 KV 池；升级到同时包含两项准入修复的构建版本；在两个角色上都启用延迟 KV 释放；在模型支持的情况下启用损坏检测；并配置负载均衡器，使客户端断开连接不会在传输中途中止请求。

Cloudflare 表示，它此前曾构建过一个原型设计，为每个物理 KV 页打上标记，并在 decode 读取缓存之前检查映射关系，测试中该设计对吞吐量和尾部延迟的影响低于 1%；该公司于 2026 年 8 月中旬在 GLM 5.2 上测试了该原型，但随后不久因可靠性问题将其停用。Cloudflare 正与 SGLang 团队合作开发内置于引擎中的生产版本，以拉取请求 #39500 中的逐次传输校验和作为第一步，并表示正在将其形式化方法经验用于对其生产 SGLang 部署中使用 Mooncake 的基于 RDMA 的 KV 缓存传输协议进行建模和安全性证明。

SGLang 团队的帖子感谢 Cloudflare 工程师 Kevin Flansburg 和 Kastan Day 在修复方面所做的工作，并将 SGLang 与 Cloudflare 于 2026 年 10 月 26 日进行的协调披露列为披露时间表中的最后一项。该研究人员的报告即将发布，SGLang 团队表示该报告将描述此次发现及外部验证。