Cloudflare GLM-5.3 跨客户数据泄露：长上下文推理里的 KV 缓存隔离问题

Cloudflare 在 2026 年 10 月 26 日 发布事故报告：8 月 27 日到 9 月 9 日之间，Workers AI 上的 GLM-5.3 模型有 155 条回复混入了其他客户此前请求里的内容。所有受影响的请求，提示长度都超过 68.128 万 Token。

这次事故和提示缓存的计费无关，出问题的是推理引擎内部的 KV 缓存。KV 缓存是模型处理提示时生成的中间结果，提示缓存功能和长上下文推理都依赖它。事故说明了一点：长上下文推理服务要做好客户之间的隔离，难度比看起来高。

事情经过

9 月 8 日，安全研究员 Gadi Evron（Knostic）通过 HackerOne 报告：向 @cf/zai-org/glm-5.3 发送很长的提示，有时会收到属于其他用户会话的文字。Cloudflare 第二天上午复现了问题，宣布事故后 40 分钟内下线模型，当天部署修复后恢复服务。

排除 Cloudflare 自己和研究员的测试后，剩余受影响请求的时间和数量符合正常的长上下文使用，Cloudflare 没有发现有人故意利用这个漏洞。其他模型没有受影响。

两个问题叠加

第一个问题是配置不匹配。 GLM-5.3 对外宣称支持 1,048,576 Token 的上下文，但负责处理提示的 GPU（预填充节点）上，KV 缓存池只能放下 681,280 Token。Cloudflare 上线前知道这个差距，以为引擎会对放不下的请求报错。长上下文测试都返回了成功状态码，所以没有当成问题。

第二个问题是 SGLang 的 bug。 Cloudflare 把提示处理和文本生成拆在两组 GPU 上运行。放不下的提示会被标记为拒绝，替换成一个 Token 的占位符。单机部署时，这个流程会正常结束并返回错误。拆分部署时，生成节点只检查请求是否“完成”，没有检查是否“被拒绝”。它收到“传输完成”的消息，以为缓存页已经被新提示完整覆盖，其实页里大部分还是前一个请求留下的数据。模型基于这些旧数据生成回复，于是把别人的内容带了出来。

缓存页在请求之间不会清零，下一个请求直接覆盖。这是推理引擎的常见做法，可以换来更高的性能，但页面归属完全靠引擎自己的记录来保证，记录一出错就会串数据。

修复方式

Cloudflare 做了两层修复：

1. 调整配置：释放 GPU 显存，让 KV 缓存池能放下约 204 万 Token，大约是上下文长度的两倍。任何合法请求都不会再走到拒绝路径。
2. 修补引擎：被拒绝的请求在分配和传输缓存之前就直接退出，并返回原本的错误；生成节点还会核对实际传输的 Token 数量。相关修复已合入 SGLang 上游，v0.5.22 及之后的版本包含这些修复。

Cloudflare 承认测试里有一个关键缺口：长上下文测试只检查了 HTTP 状态码和性能，没有检查模型输出的内容是否正确。现在每次部署变更前，都会直接从运行中的引擎核对缓存池大小和上下文长度。

API 用户能做什么

作为调用方，用户看不到服务商内部的缓存隔离，但可以降低风险：

• 不要把用不到的敏感数据放进提示。 长上下文很方便，但把整个仓库、全部客户资料一次性塞进去，出事时暴露的范围也最大。
• 注意异常输出。 如果回复里出现明显不属于自己的内容，比如陌生的代码、人名或对话，保存请求时间和请求 ID，及时报告给服务商。
• 超长上下文先小范围验证。 新模型或新线路宣称支持百万 Token 时，先用带标记的测试文本检查回答是否对得上，不要只看请求有没有成功。
• 了解服务商的数据处理方式。 包括缓存保留时间、是否跨组织共享、是否支持零数据保留。OpenAI 的文档写明，提示缓存在组织和处理区域内路由；不同服务商的说明各不相同。

对推理服务运营方的建议

Cloudflare 给使用 SGLang 拆分部署的运营方列了几条建议，其中最直接的三条是：

1. 每次修改权重、量化、并行方式或显存比例后，从引擎启动日志核对每个节点的 KV 缓存池大小。缓存池比上下文长度小时，就把上下文长度调低，不要指望代理层或引擎替你拦截。
2. 升级到包含相关修复的 SGLang v0.5.22 或更高版本。
3. 在模型支持时开启 --disaggregation-enable-kv-checksum 和 --kv-canary 等损坏检测。

长期方案是让引擎在读取每个缓存页时核对归属，发现不属于当前请求就让这一个请求失败。Cloudflare 的原型测试中，这项检查对吞吐和尾延迟的影响低于 1%，目前正在和 SGLang 团队合作做成通用功能。