Cloudflare 的 GLM-5.3 串数据事故：上下文窗口比背后的缓存还大
Cloudflare 周一晚上发了一篇事故复盘：Workers AI 上跑的 GLM-5.3，有大约两周时间，部分回复里混进了别的用户请求的数据。受影响的回复一共 155 条，全部来自长度超过 681,280 token 的提示。
原因说出来近乎乏味。模型对外宣称支持 1,048,576 token 上下文，但预填充的 KV 池只装得下 681,280 token。在 SGLang 预填充和解码分离部署的模式下，超长提示被变成一个单 token 占位符，解码节点默认预填充已经写好了 KV 缓存。其实没有写，而缓存页在请求之间不清零，于是解码阶段读到的是还留着别人数据的旧页。暴露期从 8 月 27 日到 9 月 9 日。Knostic 的 Gadi Evron 9 月 8 日通过 HackerOne 报告，Cloudflare 宣布事故后 40 分钟内把模型下线，称没有发现被蓄意利用的证据。
修复办法是把池子扩到约 204 万 token，外加 SGLang 的三个补丁。用 SGLang 分离式部署的团队应该升级到 v0.5.22。这次披露是和 SGLang 团队协调进行的。
最值得贴在墙上的是 Cloudflare 自己那句话：在长上下文上，我们只验证了 HTTP 状态码和引擎性能，没有验证模型输出是否正常连贯。百万 token 上下文本来就是卖给 agent 场景的，一个提示里塞着整个代码库、一段执行轨迹和一堆工具结果。所以长上下文下的租户隔离是 agent 安全问题，不只是推理层的细节。如果你把 agent 流量交给托管的开源模型，去问服务商他们在宣称的上限处怎么测，而不是只在上限以下测。
复盘原文：https://blog.cloudflare.com/kv-cache-exposure-remediation/ HN 讨论：https://news.ycombinator.com/item?id=50252159
← 返回所有文章
原因说出来近乎乏味。模型对外宣称支持 1,048,576 token 上下文，但预填充的 KV 池只装得下 681,280 token。在 SGLang 预填充和解码分离部署的模式下，超长提示被变成一个单 token 占位符，解码节点默认预填充已经写好了 KV 缓存。其实没有写，而缓存页在请求之间不清零，于是解码阶段读到的是还留着别人数据的旧页。暴露期从 8 月 27 日到 9 月 9 日。Knostic 的 Gadi Evron 9 月 8 日通过 HackerOne 报告，Cloudflare 宣布事故后 40 分钟内把模型下线，称没有发现被蓄意利用的证据。
修复办法是把池子扩到约 204 万 token，外加 SGLang 的三个补丁。用 SGLang 分离式部署的团队应该升级到 v0.5.22。这次披露是和 SGLang 团队协调进行的。
最值得贴在墙上的是 Cloudflare 自己那句话：在长上下文上，我们只验证了 HTTP 状态码和引擎性能，没有验证模型输出是否正常连贯。百万 token 上下文本来就是卖给 agent 场景的，一个提示里塞着整个代码库、一段执行轨迹和一堆工具结果。所以长上下文下的租户隔离是 agent 安全问题，不只是推理层的细节。如果你把 agent 流量交给托管的开源模型，去问服务商他们在宣称的上限处怎么测，而不是只在上限以下测。
复盘原文：https://blog.cloudflare.com/kv-cache-exposure-remediation/ HN 讨论：https://news.ycombinator.com/item?id=50252159
评论