Cloudflare 披露 Workers AI 的 GLM-5.3 串话事故：155 次超长提示词响应混入他人数据，根因在 SGLang
zovo约 3 分钟读完
Cloudflare 在 10 月 26 日的博客中披露，Workers AI 上的 GLM-5.3（@cf/zai-org/glm-5.3）在 2026 年 8 月 27 日至 9 月 9 日之间，对超过 681,280 token 的提示词出现过跨请求的 KV 缓存泄露：共 155 条响应里含有其他客户刚发出的请求内容。Cloudflare 称问题已修复，未发现被恶意利用的迹象，这些是它自己的说法。
01发生了什么
| 项目 | Cloudflare 披露的内容 |
|---|---|
| 受影响模型 | 仅 GLM-5.3（Z.ai 的智能体编码向文本模型），Workers AI 上其他模型未受影响 |
| 影响时间 | 2026 年 8 月 27 日上线起，到 9 月 9 日恢复服务前 |
| 触发条件 | 提示词长度超过 681,280 token（模型上下文窗口为 1,048,576 token） |
| 影响范围 | 155 条响应含其他客户请求的数据 |
| 是否被利用 | 排除自家测试和研究员测试后，其余请求的时间与数量更像正常的长上下文使用，未发现蓄意利用（Cloudflare 自述） |
02两个问题叠在一起
第一个是配置：GLM-5.3 的预填充（prefill）GPU 上，KV 缓存池只能放下 681,280 token，小于 1,048,576 的上下文窗口。Cloudflare 上线前知道这个差距，但测试只看了 HTTP 状态码和性能，没有校验输出内容，误以为引擎会妥善报错。
第二个是 SGLang 的缺陷：在预填充/解码分离的部署方式下，超长请求被调度器标记为“拒绝”，提示词被换成一个 token 的占位符，但这个请求没有被终止，而是继续把一页 KV 数据交给解码节点并报告“传输完成”。解码节点此前已按原长度预留了多页缓存，只有第一页被覆盖，其余页面还留着之前其他用户的内容，于是模型是在别人的缓存上生成回答。客户端拿到的是 HTTP 200 而不是错误。
03处置时间线（均为 UTC）
- 9 月 8 日 23:11：研究员 Gadi Evron（Knostic）通过 HackerOne 提交报告。
- 9 月 9 日 13:22 宣布安全事件，14:00 前后将该模型设为私有；19:40 修复后恢复。
- 修复内容：把预填充缓存池扩大到约 204 万 token（约为上下文长度的两倍），并给引擎打补丁，让被拒绝的请求在入队阶段就带着原始错误退出。
- SGLang 在 v0.5.20 / v0.5.21 / v0.5.22 中合入相关修复，10 月 26 日双方协同披露。
04如果你自己跑 SGLang
Cloudflare 针对分离式部署的 SGLang 给出几条建议，下列为其博客原文要点的转述：对比每个节点启动日志里的 KV 池大小和上下文长度，池更小就调低上下文长度；升级到 v0.5.22 或更高；两种角色都开启延迟释放 KV；在模型支持时开启 --disaggregation-enable-kv-checksum 和 --kv-canary 等损坏检测；让负载均衡器不要在首 token 前随意中止请求。以上建议本站未实际部署验证。
提示如果你通过 Workers AI 调用过 GLM-5.3 且发送过超过约 68 万 token 的提示词，可以对照 Cloudflare 的披露和自己的日志。是否会单独通知受影响客户，博客里没有写，本站未确认。
05值得注意的点
这次事故不是模型本身的问题，而是推理引擎的缓存页面归属管理出了错。KV 缓存页在请求间不清零是为了性能，因此引擎必须自己保证页面归属。Cloudflare 说后续会推进页面标签校验和对 KV 传输协议的形式化验证，这些目前仍是计划或原型。
核对日期：2026-10-27。
资料来源（2026-10-27 核对）
本文由 zovo 编辑撰写，转载请注明出处。
Claude Code
Hy-Memory
Octop