Cloudflare 披露 GLM-5.3 跨请求泄露：155 条回复混入其他客户的数据，根因是 KV 缓存池小于上下文加上 SGLang 缺陷
一次托管推理的租户隔离事故完整复盘。自己用 SGLang 部署模型的团队，这条里有可以直接照做的检查项。
// 要点
- 8 月 27 日到 9 月 9 日，Workers AI 上的 GLM-5.3 共有 155 条回复包含其他客户此前请求的数据，全部是超过 681,280 token 的长提示；Cloudflare 称未发现蓄意利用的证据。
- 9 月 8 日 Knostic 的研究者 Gadi Evron 经 HackerOne 报告；Cloudflare 宣布事故后 40 分钟内下线模型，当天修复恢复，10 月 26 日与研究者和 SGLang 维护方协调公开。
- 根因有二：模型按 1,048,576 token 上下文上线，但 prefill 节点 KV 缓存池只有 681,280 token，测试只看了 HTTP 状态码；SGLang 在预填充 / 解码分离模式下把被拒请求换成 1 个 token 的占位，解码节点读到了残留的旧缓存页，客户端收到的是 200 而不是 400。
- 修复后缓存池约 204 万 token；SGLang 已在 v0.5.20 修补、v0.5.21 和 v0.5.22 跟进，Cloudflare 建议所有运营方升级到 v0.5.22 或更新。
开发者视角这是自托管开源模型最容易漏掉的一类风险：没有报错，只是悄悄串数据。用 SGLang 的先升到 0.5.22；上线前从运行中的引擎核对 KV 池大小不小于宣称的上下文长度，长上下文测试要检查输出内容（放标记字符串看会不会串到别人那），不能只看状态码。AI 云盘这种多租户文件问答，我会把这条加进发布检查表。