Cloudflare曝GLM-5.3 KV缓存跨租户泄露

时间：2026年10月26日（Cloudflare 官方博客当日发布该协调披露报告，与 SGLang 的配套说明同步上线） 地点：美国旧金山（Cloudflare 总部），涉及 Workers AI 托管平台与开源推理引擎 SGLang 社区 人物：安全研究员 Gadi Evron（Knostic），2026年9月8日通过 HackerOne 向 Cloudflare 提交报告；Cloudflare 事件响应团队与推理平台工程团队；SGLang 开源推理引擎维护者；2026年9月10日 Cloudflare 与 SGLang 团队在 RadixArk 会议当面沟通修复方案 事件详情：2026年10月26日，Cloudflare 公开披露一起发生在其 Workers AI 平台上的跨请求数据泄露事故。影响窗口为 2026年8月27日至9月9日，受影响对象是托管在 Workers AI 上的 GLM-5.3 模型（@cf/zai-org/glm-5.3）。Cloudflare 称共有 155 条模型回复被污染，回复中混入了同一模型更早其他用户会话的内容；这些回复对应的提示词长度全部超过 681,280 个 token。 根因由两个问题叠加造成。第一个是配置层面的错配：Cloudflare 把 GLM-5.3 以 1,048,576 token 的上下文窗口部署上线，但 prefill GPU 上的 KV 缓存池实际只有 681,280 token 容量。Cloudflare 承认在上线前就意识到这一不匹配，但当时长上下文测试返回的是成功的 HTTP 状态码和没有错误帧的流式响应，于是判断引擎能优雅处理差异；事后复盘明确指出，当时的测试只校验了响应码与引擎性能，没有校验模型输出本身的一致性。 第二个是 SGLang 在分离式 prefill/decode 架构下处理超长请求的缺陷。当提示词长度超出 KV 缓存池时，调度器会把它标记为 rejected 并把提示词替换成一个单 token 占位符，以便请求走正常批处理流程排空，而不是真的分配内存或返回客户端错误。但修复前这条拒绝路径并未中止请求：prefill 节点照常为占位符生成了 KV 缓存，经 RDMA 通过 Mooncake 传给 decode 节点，并发出了传输完成的信号；decode 节点据此假定 prefill 已用本次请求的完整提示词覆盖了先前的 KV 缓存，实际上大部分旧状态仍原封不动地留在缓存页里。decode 随后生成回复时同时关注了这些残留页，于是把早前用户的会话内容写进了新用户的回复。 时间线方面，2026年9月8日 Gadi Evron 提交报告；9月9日上午 Cloudflare 复现了问题，在宣布事故后 40 分钟内下线该模型，部署修正配置与打过补丁的推理引擎后于当天恢复服务。Cloudflare 称未发现被蓄意利用的证据，受影响请求在时间和数量上都与正常的长上下文使用相符，并确认 Workers AI 上托管的其他模型未受影响。 修复分两层落地。一是配置层，Cloudflare 参照 GLM-5.2 的配置调整了 GLM-5.3 的部署，释放出的显存让 prefill KV 池扩充到约 204 万 token，约为上下文窗口的两倍，合规提示词因此永远不会再触发拒绝路径。二是引擎层，Cloudflare 修补了引擎，使带有待处理拒绝标记的请求在分离式准入队列阶段就带着原始错误被退出，不进入 bootstrap、显存分配或 KV 传输环节；该改动以 #38704 提交上游，同时要求 decode 节点校验实际传输的 token 数与它预留的数量一致。相关修复 #36988（9月6日合入主线）与 #38935 已随 SGLang v0.5.22 发布，Cloudflare 建议运行分离式部署的运营方升级到 v0.5.22 或自行回移补丁。 背景：Cloudflare 此前已在官方博客中介绍过其高性能大模型架构：prefill GPU 池处理提示词并产出 KV 缓存，经 Mooncake 以 RDMA 远程内存直传交给 decode GPU 池生成结果，GPU 显存中的 KV 缓存是固定大小页的共享池，页在请求之间不会被清零，下一个请求拿到同一页时直接覆写。这种设计是性能所需，但由此引擎必须自行跟踪每一页的所有权，这次事故正是所有权跟踪失效的典型案例。有开发者用约 30 行 Python 复刻了核心机制，模拟显示被污染回复中被关注的上下文有 99.2% 属于其他租户，池与上下文的容量比为 0.6497，而修复后的 204 万 token 池约为上下文窗口的 1.95 倍。 影响： - 多租户推理服务的租户隔离风险被具体化。KV 缓存转交环节位于模型之下，此前多数安全讨论集中在模型与应用层，这次事故说明基础设施层的页所有权校验同样是安全边界。 - 触发条件比想象中容易满足：不需要任何攻击工具，只需要一条超过 681,280 token 的提示词。上下文窗口持续拉长的趋势，会让池容量小于上下文窗口这类错配更容易发生。 - 对所有使用 SGLang 分离式部署的团队都有直接影响。Cloudflare 给出的运维建议是：每次变更权重、量化、并行度或显存比例后，都从引擎启动日志中读取实际 KV 池大小并与上下文长度对比，池偏小就把上下文长度降下来；升级到包含 #36988 与 #38935 的 v0.5.22 或更高版本；在 prefill 与 decode 两个角色上都开启延迟释放；为 Mooncake 传输批次设定上限；并在模型支持的情况下开启 --disaggregation-enable-kv-checksum 与 --kv-canary 校验。 - 长上下文场景的企业用户需要重新评估风险敞口。155 条回复不足以构成大规模泄露，但这类内容可能包含专有代码与业务数据。 - Cloudflare 表示正与 SGLang 团队把按页打标签、读取时校验归属的完整性检查做成引擎级通用方案，其在 GLM 5.2 上的原型吞吐与尾延迟开销低于 1%。 总结：这次披露的价值不在泄露规模，而在于它完整呈现了配置错配与引擎缺陷如何共同演化为跨租户数据泄露，以及上游开源推理引擎在多租户场景下的真实风险边界。Cloudflare 罕见地公开了自己在上线前已知容量不匹配、却因只校验状态码而放行的决策链，并同步给出引擎层补丁与可执行的运维检查清单。对任何运行 SGLang 分离式架构的团队来说，把启动日志里的 KV 池大小与上下文长度对比变成一条强制检查项，是这次事故最直接可落地的启示。 参考来源： https://blog.cloudflare.com/kv-cache-exposure-remediation/ https://dev.to/frankchu/cloudflares-glm-53-leaked-other-users-prompts-through-its-kv-cache-i-rebuilt-the-bug-in-30-2j3g https://digestai.news/story/cloudflare-fixes-glm-5-3-bug-exposing-155-customer-responses https://utopiats.com/blog/cross-request-kv-cache-exposure-in-the-glm-53-workers-ai-model-and-our-remediation-with-sglang https://signaldesk.news/cross-request-kv-cache-exposure-in-the-glm-5-3-workers-ai-model-and-our https://pan.parallax.kr/article/cloudflare-remediates-kv-cache-exposure-in-glm-5-3-workers-ai-model https://aiweekly.co/alerts/cloudflare-glm-53-on-workers-ai-leaked-155-responses-to-later-users-via-sglang https://www.everythingblog.in/blog/cross-request-kv-cache-exposure-in-the-glm-5-3-workers-ai-model-155-responses-c622b184-2760-4b7f-9cf2-3c7ba4eba151