适用对象：向托管 AI API（Workers AI 或任何其他服务）发送业务数据的团队，以及自行运行 LLM 推理服务器的人员。本文基于 Cloudflare 的官方文章，不涉及如何触发该漏洞。
持续更新中：随着机构发布更多信息，本文将会更新
截至2026年10月31日尚不清楚
- 受影响的客户数量
- 155 条响应中出现了哪些类型的数据
- 是否以及如何向个别客户发出通知
Cloudflare 与开源推理引擎背后的团队协同披露并发布了这份说明。其表示进一步的加固工作正在进行中（页面级完整性检查以及对其传输协议的形式化验证）。我们于10月31日重新查看了该文章，未发现后续通知。
使用托管 AI 的团队今天应检查什么
确认您是否在受影响范围内
据 Cloudflare 称，只有 GLM 5.3 模型受到影响，仅限于2026年8月27日至9月9日，且仅限于长度超过 681,280 个 token 的提示词。请在您自己的日志或账单中，查找该时间段内对该模型的调用，并记下提示词的长度。本站认为，如此长的提示词并不常见，因此许多团队会发现没有。
查看供应商的通知，并保留您自己的记录
Cloudflare 的文章没有描述面向客户的步骤，也没有说明如何通知个别客户。请查看您账户上的联系邮箱和控制台通知，如果您认为自己在受影响范围内，请询问您的客户经理团队。请记录发送给该模型的内容及时间，因为这是您判断影响时所需要的。
盘点输入到每项 AI 服务中的内容
对每项服务，写下您的员工和应用程序发送的数据类型（客户记录、源代码、凭据、合同）。如果其中包含一旦暴露就无法承受的数据，请将其从提示词中移除、进行脱敏，或使用为您单独隔离的部署。请完全不要把 API 密钥等机密粘贴到提示词中（密钥为何会通过 AI 工具泄露）。
将模型返回的任何内容视为可能不属于您
所报告的症状是响应中包含属于他人的文本。如果托管模型返回的文本看起来与您的提示词无关，例如其他公司的名称或代码，请停止使用该输出，保存证据，并通过供应商的安全渠道向其报告。
如果您运行自己的推理服务器，请执行引擎检查项
Cloudflare 建议同一引擎的运营方：在更改权重、量化、并行方式或内存设置之后，测量每个节点上的缓存池并与模型的上下文长度比较；升级到引擎 0.5.22 或更高版本；在模型支持的情况下启用损坏检测选项；并配置负载均衡器，避免在首个 token 之前中止请求。具体设置请阅读该文章本身。
事件经过（来自 Cloudflare）
以下内容基于 Cloudflare 2026年10月26日的文章。时间为文章中给出的 UTC 时间。
2026年8月27日
GLM 5.3 在 Workers AI 上上线。Cloudflare 表示，其缓存池小于模型的上下文长度，这一不匹配在上线前就已知晓。9月8日 23:11
通过 Cloudflare 的漏洞赏金计划收到一份报告。9月9日 13:22
Cloudflare 宣布发生安全事件。据文章称，其产品安全团队在 25 分钟内使用两个独立账户复现了该泄露。9月9日 14:00
该模型被设为私有（请求返回错误）。9月9日 14:35–19:04
确定根本原因，将预填充（prefill）节点迁移到修正后的配置，然后使用引擎补丁重建整个部署并完成验证。9月9日 19:40
该模型重新公开。9月16日 – 10月19日
上游修复已合并并在开源引擎中发布，包括10月19日发布的 0.5.22 版本。10月26日
Cloudflare 发布了其说明。
- 服务和模型
- Workers AI，GLM 5.3（由第三方开发者提供的文本生成模型）
- 暴露的内容
- 其他客户在受影响请求之前不久向同一模型发出的请求中的数据
- 谁能看到
- 其超长提示词收到了受影响响应的客户
- 原因之一
- 缓存池容量为 681,280 个 token，而上下文长度为 1,048,576 个 token
- 原因之二
- 开源推理引擎中的一个漏洞：超长请求被接受而不是被拒绝，响应引用了仍保存着先前请求数据的缓存页
- 利用情况
- 在排除 Cloudflare 自身测试和研究人员的测试后，请求在时间和数量上与普通的长上下文使用相符；没有蓄意利用的证据
- 修复
- 配置与先前的模型版本保持一致（缓存池现约 204 万个 token）、引擎补丁在接收阶段拒绝此类请求，以及在更改部署之前核对缓存池大小与上下文长度
已知与未知的信息
截至2026年10月31日的状态。
| 项目 | Cloudflare 的说法 | 状态 |
|---|---|---|
| 期间 | 2026年8月27日至9月9日 | 已确认（Cloudflare） |
| 受影响的模型 | 仅 GLM 5.3；没有其他 Workers AI 模型 | 已确认（Cloudflare） |
| 受影响的响应 | 155 条，均针对超过 681,280 个 token 的提示词 | 已确认（Cloudflare） |
| 客户数量 | “少数客户” | 未披露 |
| 暴露数据的内容 | 其他客户的近期请求 | 类型和敏感程度未披露 |
| 蓄意利用 | 未发现证据 | Cloudflare 的调查结论 |
| 个别通知 | 文章中未描述 | 未披露 |
| 修复 | 9月9日已部署；上游修复随后发布 | 已确认（Cloudflare） |
为什么共用同一缓存会在客户之间泄露
托管语言模型在同一硬件上为许多客户提供服务，并为正在处理的文本保留一份工作内存（缓存），以便更快地响应。一般而言，如果这块内存在未清除的情况下被重复使用，或者读取的大小与写入时不同，一位客户的文本就可能出现在另一位客户的输出中。这是对此类问题的一般性说明，并非关于本事件的额外细节。
在 Cloudflare 自己的说明中，有两点值得注意。缓存大小与上下文长度之间的不匹配在上线前就已知晓，而其上线前的测试检查的是状态码和流式传输，而不是输出是否合理。Cloudflare 表示，现在每次更改部署之前，都会通过运行中的引擎核对缓存池与上下文长度。对客户而言，教训是：“请求成功”并不能说明响应属于您。
面向运营 AI 服务的团队：从这份说明中得到的一项检查
如果您为多个客户或团队提供模型服务，请增加一项测试：发送超长和边界大小的输入，并检查结果是错误而不是成功的回答。此外，在更改模型权重、量化或内存设置之后，要验证缓存是否仍足以支持所宣称的上下文长度。这两项都直接来自 Cloudflare 所描述的原因。
缓存池 681,280 个 token，上下文长度 1,048,576
↓→
缓存是否至少与所宣称的上下文长度一样大？
超长请求被接受，而不是被拒绝
↓→
超长的测试输入是否返回错误？
测试检查的是状态码，而不是输出
↓→
测试是否检查输出属于该请求？
信息来源（公开记录）
- Cloudflare 博客，关于 Workers AI 模型中跨请求 KV 缓存暴露及其修复的文章（2026年10月26日）— blog.cloudflare.com
更新记录
2026-10-31：首版，基于 Cloudflare 10月26日的文章。如果 Cloudflare 或该引擎的维护者发布更多信息，我们将更新本文。
延伸阅读
- AI 与攻击者：AI 代理自行入侵系统
- 保护密钥和机密：API 密钥如何通过 AI 工具泄露
- 其他2026年事件：2026年的数据泄露和网络攻击