10月26日，Cloudflare发布了一份事故报告，承认其Workers AI平台上托管的GLM-5.3模型，曾在155条回答中混入了其他客户请求的数据。问题发生在2026年8月27日至9月9日之间，9月9日已修复。最吓人的不是数字155，而是失败的方式：系统没有报错，而是像什么都没发生一样，正常地返回了一个“看起来很对”的回答。
先讲清楚发生了什么：广告上的长度，和实际能装的长度，不一样
这个模型对外宣称的上下文窗口是1048576个Token，但预处理（prefill）环节的GPU缓存池实际只能容纳681280个Token。所有被确认受影响的回答，都来自超过681280个Token的超长提示。Cloudflare的解释是：配置不匹配叠加了开源推理引擎SGLang在分离式预处理与解码架构下的缺陷——超长请求在预处理阶段被悄悄替换成一个Token的占位符，解码端却以为“传输已完成”，于是去读那些还没被覆盖的缓存页，而那些页面里还留着其他客户的提示或部分回答。用户看到的是HTTP 200、Token数也对得上、回答也通顺，完全看不出异常。安全研究员Gadi Evron在9月8日通过Cloudflare的HackerOne项目报告了这个问题。
Cloudflare说了什么，没说什么
Cloudflare表示，在排除自身测试和研究员的请求后，剩余请求符合正常的超长上下文使用模式，未发现被蓄意利用的证据；同时确认Workers AI上只有GLM-5.3这一个模型受影响。需要提醒的是，“未发现蓄意利用”不等于“数据没有外泄”——155条回答确实已经把别人的数据给了不该拿到的人。至于这些数据具体是什么、是否涉及敏感内容，公开报告里没有展开。对用户来说，结论很直接：不要把高度敏感的信息放进超长提示里，更不要假设“大厂托管”就等于“天然隔离”。
给所有自建推理服务的人提个醒：升级和隔离测试一个都不能少
Cloudflare建议自托管SGLang的用户升级到v0.5.22或更高版本，并检查分离式部署配置。这件事的教训其实适用于所有推理平台：第一，宣称的上下文长度必须和实际的缓存容量、内存配置逐项对齐，不能只看营销数字；第二，缓存池是租户隔离边界，默认配置不会替你保证隔离，必须做跨租户的隔离测试；第三，错误处理路径本身就是攻击面——一个被“静默处理”的错误，比一个直接报错的错误危险得多，因为它会让所有人都以为一切正常。
写在最后
Cloudflare这次事故最值得记住的不是155这个数字，而是它揭示的AI基础设施真相：模型越来越大、上下文越来越长，但底层的内存、缓存和隔离机制并没有同步变得更可靠。AI的“聪明”建立在大量看不见的工程细节上，而恰恰是这些细节，决定了你的数据会不会在某一次超长对话里，悄悄跑到别人手里。
