Cloudflare 披露 GLM-5.3 数据串漏：155 条响应为何混入他人内容？

AI 接口返回成功，输入长度也记进了账单，答案却混入别人的内容——这正是 Cloudflare 刚公开的一起事故中，最容易被忽略的信号。

10 月 26 日，Cloudflare 披露：其 Workers AI 托管的 GLM-5.3 在 8 月 27 日至 9 月 9 日间出现跨客户数据暴露，共确认 155 条受影响响应，均对应超过 681,280 token 的提示。155 是响应数量，不能改写成 155 名用户或 155 家公司。

Cloudflare 表示，其他托管模型未受影响，也没有发现蓄意利用的证据。这是其调查结论，不能延伸为“没有数据暴露”。同样，这次故障的范围是特定托管部署，不能泛化为所有 GLM 模型或所有 SGLang 服务都有相同问题。

先把时间摆正：9 月修复，10 月公开

这不是 10 月 26 日才开始的一轮泄漏。公开报告给出的关键节点如下，表内时刻均为 UTC：

时间	已确认的进展
8 月 27 日	该 GLM-5.3 部署上线，问题从上线时存在
9 月 8 日 23:11	收到研究者经 HackerOne 提交的报告
9 月 9 日	模型临时下线，调整配置并打补丁；19:40 恢复公开服务
10 月 26 日	Cloudflare 与 SGLang 协调公开事件及修复说明

把“事故发生”“服务恢复”和“公开披露”分开，才能理解这条新闻的新意：现在新增的是可供外界检查的事故解释与上游修复脉络，而不是说这个托管服务仍在按原方式暴露数据。

发现者来自 Knostic。其 调查说明记录了一个反常现象：超过一定长度后，请求反而明显变快，答案也不再返回输入中专门加入的独有标记。研究者还观察到路径、发票类信息和项目内容。

这些异常本身不能直接证明服务器底层出了什么问题。Knostic 为此比较了不同长度请求、空输入和相关模型，逐步排除替代解释；服务端缓存交接的根因，则由 Cloudflare 与 SGLang 的调查说明。这一区别很重要：看见一段陌生文字，既不能随手称为“幻觉”，也不能只凭它就宣布泄漏。

一次本该拒绝的请求，为什么还能生成答案

模型处理长输入时，会把后续计算需要的中间状态放进 KV 缓存。可以把它想成工作台上的临时笔记：它属于正在处理的任务，任务结束后，工作台空间可以重新分配，但下一份任务不应读到上一份笔记。这是便于理解的比喻。

此次部署把“读输入”的 prefill 和“写答案”的 decode 分配给不同节点。根据 SGLang 团队的说明，配置允许约 105 万 token 的上下文，prefill 缓存池却只能容纳 681,280 token。于是有些请求符合对外上下文限制，却装不进实际缓存。

正常做法是明确返回错误。问题在于，被标记拒绝的请求仍进入了两端交接流程；decode 读取了未被本次请求完整覆盖的缓存页，里面可能保留此前请求的数据。

图源：Cloudflare 10 月 26 日事故报告，核查于 10 月 29 日。图中“8 页”和“1 页”用于说明交接机制，不能理解成线上缓存池只有 8 页；图内英文保留原始技术表述。

这也解释了为什么“返回 200”不是充分的验收条件。接口状态、处理时延和计费记录看起来正常，仍不等于回答依据的是本次用户输入。对于长上下文服务，内容相关性和客户之间的隔离，同样需要被验证。

早在 7 月 6 日，SGLang 的公开问题 #30233就描述过类似的拒绝请求继续解码、产生异常输出的现象。它可以帮助追溯缺陷线索，却不能单凭该日期断言某家公司当时已经知道此次生产环境的跨客户影响。

修复也分两层：Cloudflare 增大了缓存池，同时修正引擎的拒绝流程。只扩大容量仍可能在未来配置变化后再次遇到边界，所以需要让失败路径本身安全结束。上游 修复 #36988处理中止请求的收尾，后续改动则进一步提前拦截。

SGLang 的协调披露还讨论了请求中断后，远端写入尚未结束、缓存槽位却被复用的另一类风险。它与此次确定性的拒绝路径故障相关，但不应混成同一个触发原因。维护者列出了继续加固的事项，也不能把某个版本号包装成覆盖所有场景的安全保证。

对企业用户，另一处值得重新理解的是数据政策。Workers AI 的数据使用文档区分了标准推理、用户选择的存储功能和运维元数据，并承诺不使用客户内容训练模型。这样的政策回答“数据按什么规则处理”，与运行时能否正确隔离缓存，是两个都需要落实的问题。

本站此前介绍过 DeepSeek 的 DeepInfer 推理引擎。此次事故从另一个角度说明：模型之外，承载它的引擎、调度和内存管理，也会直接影响用户拿到的答案。

普通用户无须把所有 AI 错答都当作泄漏；但当回答出现明显不属于自己的项目或业务信息时，也不该因为接口显示成功就忽略它。保留必要的请求编号并向服务商报告，比继续传播其中可能属于他人的内容更有帮助。此次公开报告最有价值之处，正是让“回答成功”背后的隔离条件变得可检查。

本文补充阅读了发现者报告、SGLang 协调披露、早期问题、上游修复和数据政策等 5 份原始资料；未对线上服务进行漏洞复现。