Cloudflare 推理缓存缺陷致跨租户数据泄露

Cloudflare Workers AI 的 GLM-5.3 曾出现跨租户数据泄漏：超长提示词触发异常后，模型可能读到其他客户留在 GPU 缓存里的数据，共有 155 条响应受到影响。故障由一个容量配置错配和一条没有真正终止请求的拒绝路径共同触发。

这篇复盘值得读，因为它把三个常见的工程盲点串到了一起：HTTP 成功不代表内容正确，记录错误不代表处理已经停止，配置文件里的容量也不代表运行时真的有那么多空间。做推理服务的人要查隔离边界，接 AI API 的开发者也能从中改进测试方法。

155 条响应受影响，触发条件是什么

根据原文转述的复盘，问题发生在 2026 年 8 月 27 日至 9 月 9 日，影响 Cloudflare Workers AI 上的 @cf/zai-org/glm-5.3。这是 Z.ai 面向智能体编程的文本模型，其他 Workers AI 模型未受影响。

触发门槛是提示词超过 681,280 tokens。这类请求可能在响应中带出其他客户近期向同一模型提交的数据。

Cloudflare 表示，受影响请求的时间和数量符合正常的长上下文使用特征，没有发现蓄意利用的证据。这里要区分两件事：没有发现攻击证据，并不改变跨租户暴露已经发生的事实。

报告由 Knostic 的 Gadi Evron 通过 HackerOne 提交。按 UTC 时间，9 月 8 日 23:11 收到报告，次日 08:00 开始验证；团队用两个独立账户，在 25 分钟内复现泄漏，13:22 宣布事件，14:00 将模型设为私有，14:35 找到根因，19:04 部署修正配置，19:40 恢复公开服务。

响应和修复都在当天完成。10 月 26 日，Cloudflare 与 SGLang 协调公开复盘，距离事件约六周，上游修复已随 SGLang v0.5.21、v0.5.22 发布。

为什么请求已经被拒绝，还能读到别人的数据

先理解 KV cache。模型生成后续 token 时，会复用前面计算出的键值缓存，避免反复计算整个上下文。这些缓存存放在 GPU 显存中，按固定大小的页分配和复用。

Cloudflare 使用预填充与解码分离的部署方式：prefill GPU 处理提示词、建立 KV cache，再通过 Mooncake 使用 RDMA 将缓存交给 decode GPU，由后者生成回答。RDMA 可以理解为节点间直接传输内存数据的通道。

第一处问题出在容量上。SGLang 启动时，根据加载模型权重后剩余的 GPU 显存决定 KV 池大小；模型对外配置的上下文长度则是另一个值，两者没有被强制校验。

当时 prefill 节点的 KV 池只能容纳 681,280 tokens，配置的上下文长度却是 1,048,576。部分请求符合上下文限制，却装不进实际缓存池。

Cloudflare 上线前已知道这个差异，但长上下文测试返回了成功的 HTTP 状态码、流式响应体，也没有错误帧，团队因此认为引擎能妥善处理。他们检查了状态码和性能，没有验证输出内容及连贯性。

第二处问题让容量错配变成了数据泄漏。在 SGLang v0.5.21 之前，调度器遇到超出 KV 池容量的提示词，会调用 Req.set_finish_with_abort。这个拒绝路径记录了错误，却没有立即停止请求，而是将提示词替换成一个 token 的占位符，让请求继续经过正常批处理流程。

在分离部署中，prefill 为占位符生成缓存并传给 decode。decode 收到「传输完成」后，以为完整提示词对应的缓存已经覆盖了预留空间。

实际只写入了占位符对应的数据。为了性能，缓存页在请求之间不会清零，原本依赖下一次写入覆盖旧内容，剩余页面里便可能保留其他用户的数据。decode 随后读取这些旧缓存，生成了包含其他会话内容的响应。

错误已被记录，但请求仍在流动，下游又把流程完成当成了数据完整。

为什么扩容以后，还必须修拒绝路径

Cloudflare 做了两层修复。

第一层是调整 GLM-5.3 配置，使其与 GLM-5.2 的设置一致，释放更多 GPU 显存。调整后的 prefill KV 池约能容纳 204 万 tokens，约为上下文长度的两倍，让合法上下文请求能够装进缓存池。

第二层是修正引擎的失败处理。量化方式、张量并行、CUDA graph 大小及未来模型版本，都可能再次改变剩余显存和缓存池容量。仅靠这次扩容，无法保证以后不再触发拒绝路径。

修复后的请求如果带着待处理的拒绝状态，会在分离部署的准入队列中携带原始错误退出，在 bootstrap、内存分配和 KV 传输之前停止。同时，decode 节点会核对实际传输的 token 数量是否与预留数量一致。

Cloudflare 提交了 PR #38704，随后发现 SGLang main 已有处理相关路径的 #36988，维护者又合入了进一步提前拒绝请求的 #38935。原文称，相关改动在模型恢复上线前经过研究者复现脚本验证。团队还增加了部署检查：直接从运行中的引擎读取 KV 池容量，与上下文长度比较。

复盘也指出，这属于一类 KV 缓存内存安全问题。单节点内，生成、卸载、传输接收和中止路径可能同时持有页面；跨节点时，请求已经中止，prefill 却可能仍在通过 RDMA 写入 decode。此前的 decode 卸载问题、语法错误导致的重复释放，也属于这类生命周期管理错误。

9 月中旬之后，上游工作还包括逐次传输校验和、保留中止确认，以及默认开启延迟释放 KV。修复范围因此覆盖了更广的状态管理问题。

我的判断

我最认同的是测试边界需要延伸到内容。原文给出的直接证据很清楚：上线前测试能收到正常 HTTP 响应，但错误配置仍然通过。对生成式 API 来说，状态码只能证明协议层的一部分工作完成了。

不过，内容校验也不能单独承担隔离验证。一次回答连贯，无法证明缓存没有越界；这次最终还需要容量检查、拒绝路径修复和传输数量核对。

资源容量与请求终止语义，需要分别建立保证。

相比只扩容或降低上下文上限，修正拒绝路径能覆盖以后再次出现的容量变化。相比每次清零缓存页，原文采用了提前终止和传输校验，但没有提供不同方案的性能与安全对照数据，不能据此认定这就是所有团队的最佳取舍。

作者最后建议，无法容忍任何跨租户暴露风险时，应在自己的硬件上运行模型。这个方向能减少与陌生租户共享缓存池的风险，但自托管仍需要维护请求间隔离和缓存生命周期；如果内部也服务多个用户，同类错误仍有后果。原文没有给出自托管与托管服务的总体风险或成本比较，这部分应视为部署取舍建议。

还要保留一个证据边界：这里讨论的是所给文章对厂商复盘的转述，不能把其「无蓄意利用证据」扩大成绝对不存在攻击，也不能把单个模型事件推广到全部托管推理服务。

能拿来做什么

• 给前端或 Node 接入的 AI API 增加内容层验收：测试长上下文时，同时检查是否完成指定任务、是否出现无关内容，并覆盖流正常结束却回答异常的情况。
• 检查 Node 中的多阶段处理流程：当鉴权、参数验证或任务准入失败时，确认请求已经停止，不会在写入错误状态后继续进入队列、分配资源或执行下游操作。
• 自建 SGLang 的团队应按原文建议使用 v0.5.21 或更高版本，并核查 v0.5.21、v0.5.22 的相关修复；每次部署都从运行引擎读取实际 KV 池容量，与服务上下文长度比较，不能只查看配置文件。
• 为托管 AI 编程服务评估数据边界时，把跨租户隔离机制、事故披露和修复验证纳入考量；涉及严格隔离要求时，再比较独占部署或自有硬件方案及其维护成本。