Cloudflare称GLM-5.3漏洞导致跨租户会话泄露155条响应

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

Knostic的安全研究员Gadi Evron于2026年9月8日通过Cloudflare的HackerOne计划向其报告了租户隔离问题。从2026年8月27日起，也就是GLM 5.3在Workers AI上线当天，以@cf/zai-org/glm-5.3的名称提供服务的模型受到该问题影响。Cloudflare于2026年9月9日修复了问题并恢复模型服务，并表示已确认Workers AI托管的其他模型均未受影响。

所有155条受影响的响应都对应长度超过681,280个令牌的提示词。Cloudflare表示，排除自身测试和研究人员的请求后，已识别出的请求在时间分布和数量上符合常规的长上下文使用模式，而非对该漏洞的反复利用；公司也没有发现蓄意利用漏洞的证据。

导致数据暴露的两个问题

GLM是Z.ai推出的一款文本生成模型，专为智能体编程工作流打造，也是Workers AI提供的众多模型之一。Cloudflare使用开源推理引擎SGLang，以解耦式架构运行GLM 5.3：预填充GPU处理提示词并生成其KV缓存，随后通过Mooncake使用远程直接内存访问（RDMA）将缓存传给解码GPU，由后者生成响应。KV缓存是一个由固定大小页面组成的共享池；这些页面在不同请求之间不会清零，因此由引擎负责追踪每个页面的归属。

报告将数据暴露归因于两个问题。第一个是配置错误：Cloudflare部署GLM 5.3时设置的上下文窗口为1,048,576个令牌，但预填充GPU上的KV缓存池只能容纳681,280个令牌。Cloudflare表示，发布前已注意到这一差异，但预计引擎会对无法处理的提示词返回错误；而其长上下文测试均返回成功响应，因此公司当时并不认为这是个问题。公司称，测试验证了长上下文下的HTTP响应代码和引擎性能，却没有验证模型输出及其连贯性；如今，在任何解耦式部署变更上线之前，公司都会直接检查KV缓存池容量是否与上下文长度相符。

第二个问题是SGLang在解耦式预填充和解码模式下处理超长请求时存在漏洞。无法放入缓存池的提示词会在内部被标记为拒绝，并替换为一个仅含一个令牌的占位符；但预填充仍会为该占位符生成KV缓存，并发出传输完成的信号。随后，解码节点在处理响应时会读取仍保留着先前请求数据的过期缓存页面，客户端收到的则是HTTP 200响应，而非HTTP 400响应。

SGLang团队在其共同发布的帖子中称，单节点拒绝路径会改为返回错误，因此该问题只发生在解耦式服务中。另一名用户已于2026年7月6日向SGLang报告这一漏洞，提交的问题编号为#30233；Cloudflare表示，调查期间注意到了这一报告。

事件响应与修复

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

配置修复采用了GLM 5.2的设置，释放了足够的GPU内存，使预填充KV缓存池现在可容纳约204万个令牌，约为1,048,576个令牌上下文长度的两倍，因此，只要提示词符合上下文窗口限制，就一定能放入缓存池。引擎补丁会在解耦式准入队列中终止带有待处理拒绝状态的请求，并保留其原始错误；此操作发生在任何引导、分配或KV缓存传输之前。恢复模型前，Cloudflare使用研究人员的复现脚本及自身的金丝雀标记测试验证了这两项变更。

上游修复与后续工作

Cloudflare通过SGLang拉取请求#38704向上游提交了修复方案；维护人员随后合并了#38935，按照Cloudflare的方案在准入阶段拒绝受影响的请求。另一项相关修复#36988已于2026年9月6日合并，用于处理一条相关故障路径。该补丁随SGLang v0.5.20发布，后续更新还包括v0.5.21（2026年10月2日发布）和v0.5.22（2026年10月19日发布）；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 的报告建议：每当权重、量化方式、并行度或内存占比发生变化后，都在每个预填充节点和解码节点上，根据上下文长度测量 KV 池；升级到同时包含两项准入修复的构建版本；在两种角色的节点上都启用延迟释放 KV；在模型支持的情况下启用损坏检测；并配置负载均衡器，确保客户端断开连接不会导致请求在传输过程中中止。

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

SGLang 团队在公告中感谢 Cloudflare 工程师 Kevin Flansburg 和 Kastan Day 为这些修复所做的工作，并将 SGLang 与 Cloudflare 于 2026 年 10 月 26 日进行的协调披露列为披露时间线的最后一项。SGLang 团队表示，研究人员本人撰写的报告将介绍此次发现和外部验证，目前尚未发布。