国产模型 GLM-5.3 在 Cloudflare 翻车、155 条回复串了别人的数据、超长对话才触发

聊天记录，可能出现在别人屏幕上

10 月 26 日，Cloudflare 发布了一份事故复盘报告。

标题看着平平无奇，讲的却是一件相当炸的事：托管在 Cloudflare Workers AI 上的国产模型 GLM-5.3，有 155 条回复里混进了别人的聊天内容。

先说最重要的一句：智谱不是责任方。 漏洞出在 Cloudflare 自己的部署配置，加上上游开源推理引擎 SGLang 的一个缺陷。

用人话说： 你把文件交给一家打印店复印，结果复印机的缓存没清干净，上一位客户的文件残留在了你的复印件里。这是打印店的锅，不是你交的文件有问题。

一句话总结

Cloudflare 托管的 GLM-5.3 在 8 月 27 日到 9 月 9 日的 13 天里，有 155 条 AI 回复被别人的上下文污染——只有当提示词超过 68 万 token 才会触发，而触发条件暴露出的真正问题，是"缓存池比上下文窗口小"这个部署常识，和"只测状态码不测输出"这种上线习惯。

一、到底泄漏了什么

先看几个关键数字：

项目 · 数据

影响的端点 · @cf/zai-org/glm-5.3（Cloudflare Workers AI）

泄漏窗口 · 2026-08-27 至 2026-09-09，约 13 天

受影响响应 · 155 条

触发门槛 · 提示长度超过 681,280 token

模型上下文窗口 · 1,048,576 token

GPU 预填充缓存池 · 只有 681,280 token

先解释一下 token。大致上，中文一个汉字算 1 到 2 个 token，英文一个单词大概 1 个 token。所以 68 万 token 大致相当于几十万字到上百万字的对话量。

也就是说：普通聊天根本碰不到这个坑。 你得往 AI 里塞一本长到离谱的书，才可能触发。

用人话说： 这是一个"只有极端用法才会遇到"的漏洞。对绝大多数人来说，看到这条新闻的第一反应应该是"那我没事"，而不是"我的隐私没了"。

报告者是安全公司 Knostic 的研究员 Gadi Evron，他在 9 月 8 日 23:11 UTC 通过 HackerOne 提交了这个漏洞。

Cloudflare 的调查结论是：没有发现蓄意利用的证据，时间线和流量特征都符合正常的超长上下文使用。也就是说，不是有黑客进来捞数据，而是配置错误自己漏的。

二、为什么会漏：两个问题叠在一起

Cloudflare 的复盘把根因拆成了两条，这两条单独存在都不致命，叠在一起就出事。

第一条：配置错配。

模型上下文窗口是 1,048,576 token，但 GPU 上的预填充 KV 缓存池只有 681,280 token。

而这个缓存池的大小是按剩余显存自动推导出来的，不是配置项——也就是说，运维人员根本不知道它是这么小。

Cloudflare 在自己的博客里写得很坦白：上线前他们知道这个错配存在，但只测了 HTTP 状态码和性能，没有测输出的连贯性。

用人话说： 系统的门牌号上写着"这栋楼住 100 户"，实际只盖了 65 户。验收的时候他们只查了"楼能不能进、电梯快不快"，没查"住满 100 户的时候，第 66 户住的是谁"。

第二条：SGLang 在 prefill/decode 分离模式下的缺陷。

这条更技术，但可以说得形象一点。

当你的提示词长到超过缓存池容量时，系统会拒绝这个请求。问题是——它只做了"拒绝"这个标记，把请求换成了一个 1 token 的占位符，但并没有真正中止。

于是 prefill 阶段照常为这个占位符生成了 KV 缓存，还把它传给了 decode 阶段。而 decode 阶段收到"传输完成"的信号后，就默认缓存已经被覆盖了，于是去读了一块留着别人数据的陈旧缓存页。

这个缺陷在上游 SGLang 仓库有对应 issue：#30233，2026 年 7 月 6 日。

三、那天下午的 5 个半小时

9 月 9 日的处置时间线，是这次复盘里最值得看的部分。

时间（9 月 9 日） · 动作

14:00 · 端点私有化，停止对外服务

14:35 · 定位根因

19:04 · 完整修正部署完成

19:40 · 恢复公开服务

从服务下线到恢复公开，一共 5 小时 40 分钟。其中定位根因用了 35 分钟，剩下 4 个半小时花在部署修正和验证上。

用人话说： 整个过程中最值得学的不是技术，是先止血再复盘的顺序——先私有化掐断入口，再花时间找原因。如果反过来，先开会研究、边查边服务，那 13 天里的每一次超长请求都在继续漏。

修复方案有三条：

第一，把缓存池扩到约 204 万 token，差不多是上下文窗口的两倍，从根上消除错配。

第二，被拒请求在准入闸口就"退休"——直接拦在门外，不再进到后面的流程。

第三，升级 SGLang。 v0.5.20 修了主问题，v0.5.21 和 v0.5.22（10 月 19 日发布）做跟进。上游 PR 是 #38704，维护者合并了 #38935 和 #36988。Cloudflare 建议所有跑分离式 SGLang 的运维方至少升到 v0.5.22。

四、对普通人意味着什么

先说结论：这次事件里，智谱和 Cloudflare 官方渠道的用户不在受影响范围内。 公布出来的受影响端点，是部署在 Cloudflare Workers AI 上的那个 @cf/zai-org/glm-5.3。如果你用的是智谱自己的 App 或自己的 API，那条路径不在这次披露的范围内。

值得记住的三件事：

第一，"AI 会不会记住我说的话"这个问题，从此有了具体的技术答案。 模型本身不存你的对话，存的是部署时的缓存。缓存配错了，你的上下文就可能出现在别人的回答里。

第二，触发条件极端，但它同时告诉你一件事：68 万 token 意味着几十万字的输入。当你真要把一整本书、一整个代码库、一堆公司文件喂给 AI 的时候，这就是"AI 会不会记住这些"这个问题的现实场景。

第三，自建 AI 服务的人要留意了。 如果你或你的公司在跑分离式 SGLang，Cloudflare 这次的教训直接适用：检查缓存池和上下文窗口的大小关系，并且在上线前测一测"极端输入下输出的连贯性"——只测状态码，是很多团队共同的习惯性盲区。

用人话说： 这次翻车最像我们每个人都会犯的一个错——不是能力不够，是想当然。想当然缓存够大，想当然拒绝就等于拦住了，想当然状态码 200 就没事。

写在最后

1、这不是智谱的锅，也不是"国产模型的锅"

出问题的三个环节是：Cloudflare 的部署配置、SGLang 引擎的一个已知缺陷、以及上游的修复没被及时打上。

换任何一家模型托管在同一个地方、跑同一个引擎版本，都会出同样的事。 把锅扣到模型厂商头上，是最省事也最没技术含量的判断。

2、每一起事故里都有一个"本不该犯"的错误

155 条回复背后，是两个"单独看都不算错"的决定加在一起。

上线前知道有错配但没测输出连贯性，这是流程问题；引擎把"标记拒绝"当成了"已经中止"，这是边界条件没处理干净。

AI 基础设施现在还处在"野蛮生长"阶段，事故多不是意外，是这个阶段该付的学费。

3、普通用户该有的判断力：看触发条件，不看标题

"155 条回复串了别人的数据"这个标题，天然让人恐慌。但68 万 token 的触发门槛，才是你判断"这事跟我有没有关系"的唯一标准。

看到安全新闻先问一句：什么条件下才会中招？ 这个问题能过滤掉九成不必要的焦虑，也能帮你识别出真正该警惕的那一成。

未来一年 AI 基础设施出事的概率只会上升，因为部署量在涨、模型在变长、缓存和上下文的边界条件却还是那套老办法。谁先把"上线前测极端输入"变成肌肉记忆，谁的 AI 服务就敢让人真用。

如果觉得这篇拆解对你有帮助，不妨点个关注和在看。

你的 AI 陪跑伙伴 【数字新奇点】 会继续关注 AI 安全和底层基础设施的进展。

咱们下期见！

参考资料

Cloudflare 官方复盘：KV 缓存暴露事件处置全过程

Cloudflare 致歉：GLM-5.3 模型出现数据泄露

Cloudflare 修复 KV 缓存暴露问题，155 条响应受影响

Cloudflare GLM-5.3 漏洞致 155 条响应暴露其他用户数据

Cloudflare GLM KV 缓存暴露修复详情