Cloudflare 发布了一份详细的事件报告，描述了其无服务器 AI 平台中的缓存处理错误如何导致 GLM-5.3 模型部署的至少 155 个用户收到包含其他客户提示和输出片段的响应。该报告于 10 月 26 日作为与 SGLang 开源推理引擎项目的协调披露发布，罕见地向公众展示了多租户 LLM 服务的内部情况，并对 GPU 内存的安全假设提出了警告。

如何发现泄漏 更多相关背景，请参阅我们的AI最新动态。

据 Cloudflare 报道，Knostic 的安全研究员 Gadi Evron 于 2026 年 9 月 8 日通过其 HackerOne 漏洞赏金计划向该公司发出了警报。 Evron 报告称，发送到 Cloudflare Workers AI 平台上的 GLM-5.3 模型的很长提示有时会返回属于其他用户会话的文本。 Cloudflare 于第二天早上重现了该问题，并于当天禁用了该模型，并在部署修复后于 9 月 9 日恢复了该模型。

受影响的模型是 @cf/zai-org/glm-5.3 — Cloudflare 通过该公司的无服务器推理平台 Workers AI 提供的来自 Z.ai 的代理编码模型。 Cloudflare 确认平台上托管的其他模型没有受到影响。

实际发生了什么

该事件可以追溯到两个重叠的问题，一个是操作问题，另一个是发动机本身的问题。

首先，配置错误。 Cloudflare 部署了具有 1,048,576 个令牌上下文窗口的 GLM-5.3，但其预填充 GPU 上的键值 (KV) 缓存池仅具有容纳 681,280 个令牌的空间。该公司承认在发布之前就意识到了这种不匹配，并希望推理引擎能够安全地拒绝超长请求。

第二，引擎故障。在分解预填充/解码模式下（Workers AI 使用的架构，其中一个 GPU 池处理提示并将生成的 KV 缓存交给生成响应的单独 GPU 池），SGLang 错误地处理了超长请求。不适合池的提示在内部标记为拒绝并替换为单令牌占位符。但预填充阶段并没有中止请求并返回客户端错误，而是为占位符提示生成 KV 缓存并将其传输到解码节点，然后解码节点生成一个响应，该响应混合了共享相同内存页面的先前请求的剩余数据。

结果：8 月 27 日至 9 月 9 日期间，少数使用该模型的客户收到了响应，其中包含其他客户在他们之前不久提出的请求的数据。 Cloudflare 发现，总共有 155 个响应受到影响，所有响应的提示长度均超过 681,280 个令牌。

没有蓄意利用的证据

Cloudflare 表示，在排除自己的测试和研究人员的验证请求后，受影响的请求在时间和数量上与普通的长上下文使用一致，并且该公司没有发现任何证据表明有人故意利用该漏洞。由于每个受影响的请求都超出了容量不足的池的容量，因此暴露窗口受到严格限制——这是由于导致问题的配置错误而带来的一线希望。

修复：更大的池和更安全的故障路径

补救措施对故障的两个层面都起作用。 Cloudflare 重新配置了其 GLM-5.3 部署以匹配其 GLM-5.2 配置，释放了足够的 GPU 内存，使预填充 KV 池现在可容纳约 204 万个令牌，大约是模型 1,048,576 个令牌上下文长度的两倍。适合上下文窗口的提示现在始终适合池。

但该公司还强调，仅依赖池大小是脆弱的：量化、张量并行性、CUDA 图形大小或未来模型版本的更改可能会默默地改变池大小。因此，它还修补了 SGLang 的拒绝路径本身，确保被拒绝的请求干净地中止，而不是为占位符生成和传输缓存。在模型恢复之前，这两项更改都根据研究人员的复制脚本和 Cloudflare 自己的金丝雀标记测试进行了验证，并且修复程序已向上游 SGLang 维护人员提供。

为什么共享 GPU 内存是一个安全问题

该报告解释了一种会让许多应用程序开发人员感到惊讶的做法：推理引擎通常不会在请求之间将 KV 缓存页面清零，因为下一个请求只会覆盖它们。这是一种故意的性能权衡，在推理引擎中很常见，但正如本次事件所示，任何在这些页面被完全覆盖之前生成响应的路径都会将性能优化转化为数据泄漏向量。

开发者社区发现了这一消息：这个故事在几个小时内就在 Hacker News 上达到了 123 个点，讨论的重点是故障模式（一个应该大声失败而不是在损坏状态下默默进行的请求）如何反映分布式系统工程的经典教训。

人工智能基础设施的更广泛的教训

这一事件提醒人们，人工智能应用的安全范围现已深入推理基础设施。多租户模型服务通过共享加速器、共享缓存池以及日益奇特的架构（如分解预填充和远程直接内存访问）集中许多客户的数据。模型的广告上下文窗口与为其提供服务而配置的物理容量之间的细微不匹配足以破坏租户隔离。

对于构建在无服务器 AI 平台上的企业来说，Cloudflare 报告的要点是双重的：LLM 服务中的租户隔离错误是真实存在的，并且已经在生产中发生，供应商的响应时间（从报告到禁用不到 24 小时，一天修复和恢复）是任何处理敏感提示的提供商要求的尽职标准。

---

掌握AI最新动态

获取最新的AI新闻、分析和突破——尽在一处。

阅读更多AI新闻 →