一条两百的回复，装着别人的上下文 (2026)

十月二十六号，Cloudflare 公开了一起已经有结论的事故：八月二十七日到九月九日，它家的 Workers AI 平台上，模型 GLM 5.3（Z.ai 的模型）有一百五十五条回复里混进了别的客户此前发过的内容。1

这些回复有两个共同点：状态码是两百，读起来通顺连贯。它们全部来自超过 681,280 词元的提示词——一个普通人几乎碰不到的长度。发现者是安全公司 Knostic 的负责人 Gadi Evron，他在九月八日通过漏洞奖励平台报告；Cloudflare 次日用两个独立账号在二十五分钟内复现，当天下午下架模型，晚上十九点四十分恢复。官方表示，排除自身与研究者的测试之后，其余请求的时间与体量都和普通的长上下文使用一致，没有发现蓄意利用。1

上下文不是被模型"记住"的。 模型读提示词时，会为每个词元算出一份中间结果保存下来，生成时每一步都要回看它，这份东西叫键值缓存。它不是一个请求独占一段内存，而是被切成固定大小的页，用完归还，由下一位使用者覆盖；页面不在请求之间清零，这是业内为性能做的通行选择，隔离靠的是引擎记住每一页归谁。2

两个缺陷叠在一起。 第一是配置失配：GLM 5.3 对外开放的上下文是 1,048,576 词元，而预填充那批显卡的缓存池只装得下 681,280 词元；池子大小由启动时剩余显存算出，与上下文长度没有任何强制约束。1 第二是引擎缺陷：在预填充／解码分离的部署里，被拒绝的超长请求内部被换成单 token 占位符，仍走完了交接流程；解码端读到的是没有为本请求写入的旧缓存页。2

真正值得记的是他们自己写出的测试缺口：发布前只验证了返回码和引擎性能，没有验证模型输出与连贯性。1

同一族里更难查的一半。 SGLang 在同一天发布了联合披露，讲另一类缺陷：预填充／解码分离下，请求中途中断时已交给网卡的远程直接内存访问写入无法取消；解码端若立刻归还槽位，迟到的写会落进别人的缓存，同样不报错。这类问题自 2025 年初 v0.4.x 起影响默认的分离部署，直到 v0.5.21（MORI 后端为 v0.5.22）。2

官方给的复现很有画面感：在 2×H200 上用 Mooncake over RDMA，受害请求一路数到 80 都正确，随后输出变成了捐赠方的提示词原文。他们给出的确定性复现脚本公开在 gist 与 PR #32564 里。2

修复分三层，代价也被量化了。

配置：预填充缓存池调到约 204 万词元，是上下文长度的两倍，正常请求永远走不到拒绝路径。1
引擎：被拒绝的请求在进入交接前就带着原错误退出，对应上游 PR #36988 与 #38935，建议所有运营方升级到 v0.5.22 或更高。2
时序：中断时延迟归还内存页，等所有写出方回报排空后再释放，超时作为兜底。2

性能账：21 组 2×H100 测试中，吞吐与延迟差异在 ±2% 以内；默认开启延迟归还的 16 组测量为 −0.38%，置信区间跨零。更彻底的方案是在每次读取时校验页面归属，原型开销低于 1%，但 2026 年 8 月中在 GLM 5.2 上试用后因可靠性问题关闭，接下来计划用形式化验证证明搬运协议。2

对你手上的活，改的是哪一句。 用 API 的人不用恐慌，但要记住隔离不只在登录那一层；可以问供应商一个具体问题：请求超过你们的缓存池时，引擎返回错误还是照常生成。自己部署的人，先量缓存池与上下文长度是否一致，再升级版本，再把延迟归还与完整性校验打开。做产品的人，把"通不通"之外的"对不对"写进长上下文功能的验收清单——本次修复就是这样验证的：在提示词里埋独有标记，再看返回内容里有没有不该出现的字符串。1

能自己核的，和还不能核的。 能核的是时间线、影响范围、配置数值、上游补丁与性能测试，这些都有当事方与引擎方两份公开记录。还不能核的有两点：一百五十五条与"未发现蓄意利用"是 Cloudflare 自己的统计，第三方尚未复核；发现者只说明这是一类独立的推理层漏洞，他的技术报告尚未发布。3