Cloudflare 披露托管 GLM-5.3 模型的跨请求数据泄露

Cloudflare 披露托管 GLM-5.3 模型的跨请求数据泄露

10 月 26 日，Cloudflare 发布事后报告，说明其 Workers AI 服务中的一个租户隔离缺陷。Knostic 的安全研究员 Gadi Evron 在 9 月 8 日报告：向 GLM-5.3 模型（`@cf/zai-org/glm-5.3`）发送极长的提示词时，返回的文字有时来自其他客户的会话。Cloudflare 称，该问题自模型 8 月 27 日上线起就存在，公司在 9 月 9 日下线模型并于当天恢复，其他 Workers AI 模型未受影响。报告标注 10 月 26 日，是因为它与开源推理引擎 SGLang 的文章协调同步发布；事件本身早了约七周。本刊 10 月 27 日这一期记录的是这次披露，而不是新的攻击。

Cloudflare 给出了数量：共有 155 条响应受影响，且提示词都长于 681,280 个 token。这里的 token 是模型读取的文本计量单位，不是加密货币。排除自家测试和研究员的测试之后，Cloudflare 称其余请求在时间和数量上与正常的长上下文使用一致，没有发现蓄意利用的证据。这是公司自己的结论。文章没有说明受影响的客户有多少，也没有说明泄露的文字包含什么内容。

两个缺陷叠加

第一个缺陷是配置不匹配。Cloudflare 把模型部署为 1,048,576 个 token 的上下文窗口，但预填充（prefill）GPU 上存放注意力缓存（KV 缓存）的显存池只能容纳 681,280 个 token。公司说上线前就知道这个差距，并预期引擎会对放不下的提示词返回错误。长上下文测试返回的都是成功响应，团队因此没有把差距当成问题。现在它承认，当时的测试只检查了 HTTP 状态码和速度，没有检查输出内容是否合理。

第二个缺陷是 SGLang 在预填充与解码使用不同 GPU 池时的程序错误。过长的提示词被标记为拒绝，并被换成只有一个 token 的替身提示，但请求本身没有被终止。预填充只写入一页缓存，就通知解码节点传输已经完成。Cloudflare 示意图中的一个例子是：解码节点为真实提示词预留八页，并认定八页都是新数据；其中七页仍保留着之前请求留下的内容，于是模型一边读着别人的残留数据一边作答。客户收到的是正常的成功响应，而不是错误。Cloudflare 指出，缓存页在请求之间不会清零。推理引擎为了速度普遍接受这种做法，这意味着引擎自己必须跟踪每一页归谁所有。

这个缺陷之所以难以察觉，是因为表面一切正常。报告写道，受影响的响应返回的是 HTTP 200 而不是 400，提示词的 token 计数与长提示词相符，回答读起来也连贯。唯一的异常是速度：这类响应比八页预填充应有的耗时更快。也就是说，只看状态码和计费数字的监控发现不了问题，必须检查输出内容或缓存页的归属，才可能在出事之前抓到它。Cloudflare 把这一点称为自己测试中的一个关键缺口。

Cloudflare 做了哪些修复

报告给出的时间线如下：9 月 9 日 UTC 13:22 宣布安全事件，14:00 把模型设为私有，14:35 找到根因，19:40 以修正后的配置和打过补丁的引擎重新公开。预填充缓存池现在能容纳约 204 万个 token，约为上下文窗口的两倍，合法的提示词因此总能放得下。Cloudflare 还给引擎打了补丁，被拒绝的请求会在任何缓存传输开始之前就被终止。SGLang 在 v0.5.20 至 v0.5.22 中发布了相关修复，Cloudflare 敦促所有使用分离式 SGLang 的部署方升级到 v0.5.22 或更高版本。它还列出更广泛的加固措施：延迟释放缓存页、限制传输批次大小，以及在部署前检查缓存池大小是否小于上下文长度。

读者能从中得到什么

对购买托管推理服务的人来说，这个教训范围不大，但很实用。按报告所述，收到泄漏内容的请求提示词都长于 681,280 个 token；被泄漏数据所来自的其他客户请求有多长，报告没有说明。然而，隔离缺陷可以在没有任何错误提示的情况下潜伏 13 天，这次就是如此。自己运行推理引擎的团队应当把缓存容量与对外宣称的上下文长度对照检查，测试输出的内容而不只是状态码，并为外部研究员保留清晰的报告渠道。Cloudflare 的说明属于厂商自述，文章没有包含对这些数量的独立核查，也没有量化对客户的影响。