Cloudflare 披露 GLM-5.3 跨请求缓存泄露：一次配置与引擎叠出来的事故

Cloudflare 于 2026 年 10 月 26 日公开一起已修复的事件：Workers AI 上的 GLM-5.3 因为 KV 池小于上下文窗口，叠加 SGLang 在分离式推理下对被拒请求的错误处理，超长提示的返回里可能混入其他用户的数据；共 155 条响应受影响，模型在 9 月 9 日下线约 40 分钟后恢复，修复同时推到 SGLang 上游。

这次发布的是什么

Cloudflare 在 2026 年 10 月 26 日发布一份事后复盘，公开了一起已经处理完毕的租户隔离事件：其 Workers AI 平台上托管的 GLM-5.3 模型（型号标识 cf/zai-org/glm-5.3），在收到极长提示时，返回内容里可能夹杂其他客户请求的数据。

事件的处置发生在 9 月。按官方给出的时间线：2026 年 8 月 27 日该模型上线，问题从那天起就存在；9 月 8 日 23:11，安全研究员 Gadi Evron（来自 Knostic）通过 HackerOne 报告，说发给该模型的超长提示有时会返回属于别人会话的文本；9 月 9 日 13:22 宣布进入事件响应，25 分钟内用两个独立账号复现，14:00 把模型设为私有、请求返回错误码，19:04 用修正后的配置与引擎补丁完成重建并验证，19:40 恢复公开访问。

影响面被写得很具体：共 155 条响应受影响，全部来自长度超过 681,280 token 的提示。官方说，剔除自家测试与研究员复现的部分之后，这些请求在时间与数量上与正常的长上下文使用一致，没有发现被刻意利用的证据。同时明确只有 GLM-5.3 受影响，其他托管在 Workers AI 上的模型未受影响。

可用性与限制

• 当前状态：模型已在 9 月 9 日恢复公开访问，配置与引擎两侧都已改过；本文发布时它处于正常服务状态。
• 影响范围：只有 GLM-5.3 一个型号；触发条件是提示长度超过 681,280 token，短提示不进入出问题的代码路径。
• 数据侧结论：155 条响应受影响，官方未发现蓄意利用的证据，也没有给出「需要用户轮换密钥」这类动作——因为泄露的不是凭证，是别人的上下文内容。
• 对运营者的意义：这类问题的修复不只在 Cloudflare 内部，相关补丁已推到 SGLang 上游，自行部署该推理引擎的团队需要按版本自查。
• 获取方式：复盘正文在 Cloudflare 博客公开，含完整时间线、根因说明与运营者清单，无需登录；具体配置项取值以官方文档为准。

主要功能

这份复盘实际给出的是一套可复用的排查清单，而不是新功能：

• 把 KV 池容量与上下文长度放在同一张表里对齐
• 在被拒请求进入调度队列时就地退休，而不是让占位符继续流转
• 让解码节点校验传输的 token 数与预留数是否一致
• 在分离式部署变更时强制检查 KV 池指标
• 用校验和与金丝雀标记检测缓存被污染
• 限制传输批次，避免超时调用留下无界尾部写入
• 调整负载均衡，让请求走到第一个 token 再决定是否中止

技术原理

根因是两件事叠在一起。第一件是配置：Cloudflare 给 GLM-5.3 配了 1,048,576 token 的上下文窗口，但 prefill 显卡上的 KV 缓存池只装得下 681,280 token。他们当时知道这个不一致，但假设引擎会对装不下的提示返回错误——而长上下文测试里返回的确实是成功响应，于是这道缺口被漏过去了。

第二件是引擎：当提示长度超过池容量时，SGLang 的调度器会把请求标记为拒绝，并把提示替换成一个 token 的占位符。问题出在分离式 prefill/decode 模式下——它没有中止请求、也没有给客户端返回错误，而是照着这个占位符算出了 KV 缓存并传给解码节点。解码节点收到「传输完成」，就认为 prefill 已经用本次请求的完整提示覆盖了缓存，实际上旧的缓存页还留着上一次请求的大部分状态。于是解码阶段一边生成，一边attending 到这些陈旧的缓存页上，返回内容里就带出了别人的数据。

客户端看到的现象很能说明问题：本该是 400，拿到的是 200；prompt_tokens 与长提示对得上，回答也通顺；但它比一次八页规模的 prefill 应有的速度快，而且里面出现了别的用户的片段。第四步自查时，「快得不正常」比「内容错乱」更值得警觉。

修复也分两侧。配置侧把池子扩到约 204 万 token，约为上下文长度的两倍，使合法请求再也走不到拒绝分支；引擎侧让带有待处理拒绝的请求在分流承接队列就被退休，并在解码节点加一道 token 数校验。Cloudflare 把补丁草案提给上游（PR 38704），SGLang 随后在 36988、38935 两个 PR 里落地，随 v0.5.20 与 v0.5.21 发布，之后的 v0.5.22 又补了一批加固。

实际体验

如果你在自建分离式推理服务，下面几步可以在半小时内完成一次体检：

第一步，量池子。从引擎启动日志里读出 prefill 与 decode 两侧的 KV 池容量，写成两个数字；再把模型的上下文长度抄在旁边。池子小于上下文长度，就属于这次的问题形态。

第二步，核对版本。查你用的 SGLang 版本是否已包含上述两个 PR；官方建议升到 v0.5.22 或更高。只升级不量池子是不够的，只量池子不升级也缺了兜底。

第三步，看开关。deferred KV release 是否在两侧都生效，传输批次是否设了上界，校验和与金丝雀检测是否开启——后两项官方说明当前还没覆盖所有模型架构，要回日志确认请求确实被校验过。

第四步，复现思路。用一个超过池容量的超长提示打过去，正常结果应当是明确的错误返回，而不是 200 加一段通顺但内容越界的回答；如果你拿到的是后者，说明请求仍在走旧的拒绝路径。

第五步，查代理。把负载均衡配成允许请求跑到第一个 token 再决定是否中止，避免客户端断连引发的跨节点 abort 竞争——官方把它列为加固项之一。

项目地址与获取方式

复盘正文在 Cloudflare 博客的安全分类下，标题为跨请求 KV 缓存暴露与 SGLang 修复，页内含完整时间线与运营者清单。相关补丁在 SGLang 的 GitHub 仓库，可用 PR 号或版本号检索。对自己的部署做自查时，以你所用引擎版本文档里的参数名为准，不要照抄博客里的示例值。

适合谁用

• 自建 SGLang 分离式推理的团队：本次的引擎侧问题与部署模式直接相关。
• 在托管平台上跑长上下文任务的开发者：知道触发条件是「超过池容量的提示」，能帮你判断自己的调用是否落在风险面内。
• 做 AI 应用安全评审的人：这是一份结构完整的事故复盘样本，配置错、引擎错、测试盲区三层都写清楚了。
• 只调用短提示接口的普通用户：影响面很窄，了解即可，不必因此调整用法。

常见问题

我通过 Workers AI 调用过 GLM-5.3，需要做什么？

先看长度。触发条件是提示超过 681,280 token，普通对话与常规文档处理远低于这个量级。如果你的调用确实达到过这个规模，并且收到过「内容像别人的」这类异常回答，可以通过 Cloudflare 的 HackerOne 渠道反馈；官方未在复盘中给出面向终端用户的批量通知或密钥轮换要求。

为什么配置错了那么久没被发现？

因为测试只验证了一半。官方自己写明：长上下文测试只核对了 HTTP 状态码与引擎性能，没有核对模型输出的内容与连贯性——请求返回 200、速度正常，就被当成通过。这个盲区比 bug 本身更值得抄进自己的测试清单。

只升级 SGLang 就够了吗？

不够，但也不能只改配置。扩池子让合法请求走不到拒绝分支，属于「不出事」；升级引擎让超长请求在交接前就被拒掉，属于「出事了也不越界」。官方把两者并列为必做项，还额外要求把池容量与上下文长度的比对纳入每次部署变更的检查。

其他模型会不会有同样的问题？

按复盘的说法，Workers AI 上其他分离式部署的 KV 池在 prefill 与 decode 两侧都大于上下文长度，请求到不了拒绝路径，因此未受影响。但这只是对该平台的结论；自建环境要自己量，不能套用。

相关工具与内容

• GLM-5.3 上架 Amazon Bedrock
• Cloudflare 发布 Clairic 抽取模型
• MCP 官方参考服务器 2.1.0 安全修复
• 智谱清言工具页
• AI 编程