---
title: "Cloudflare 披露：SGLang KV 缓存漏洞导致 GLM-5.3 回答泄露其他用户数据"
dek: "Cloudflare 称，缓存池容量不足与请求拒绝处理漏洞共同导致 Workers AI 的 155 条回答受到影响，并建议升级至 SGLang v0.5.22 或更高版本。"
---

2026 年 10 月 26 日，Cloudflare 与研究人员及 SGLang 维护者协调披露了 Workers AI 上 GLM-5.3 的跨请求 KV 缓存泄露事件。Cloudflare 称，只有 GLM-5.3 受到影响：155 条回答包含其他客户的数据，对应提示词均超过 681,280 个 token。公司未发现蓄意利用的证据。[^1]

问题由两层故障叠加而成。Cloudflare 为模型配置了 1,048,576 个 token 的上下文窗口，但预填充 GPU 的 KV 缓存池只能容纳 681,280 个 token。在 SGLang 的预填充与解码分离流程中，超出容量的请求虽被标记为拒绝，并替换成单 token 占位输入，却仍被判断为存活。预填充端处理占位输入后发出传输完成信号；解码端误以为完整提示词的缓存已经到达，随后读取了仍残留先前请求数据的缓存页。[^1]

泄露自模型于 2026 年 8 月 27 日上线时就已存在。Knostic 的 Gadi Evron 于 9 月 8 日通过 HackerOne 报告问题。Cloudflare 于 9 月 9 日 13:22 宣布安全事件，并于当天 19:40 恢复模型服务，时间均为 UTC。[^1]

SGLang 于 2026 年 9 月 6 日合并 #36988，为已中止的预填充结果补充清理逻辑；Cloudflare 将其列为阻止此次泄露的修复。[^1][^3] 9 月 16 日合并的 #38935 则在准入阶段更早拒绝请求。该 PR 的说明明确指出，在 #36988 之后，这项改动改善的是资源浪费和延迟，并非进一步修复正确性问题。[^4]

Cloudflare 在恢复服务前，将缓存池扩至约 204 万个 token，并修补请求拒绝流程。公司建议升级至 SGLang v0.5.22 或更高版本，检查缓存池容量，启用 KV 缓存延迟释放，并限制传输批次大小。它还建议在支持的架构上启用传输校验和与 KV 金丝雀检测，但说明两者尚未覆盖所有架构，包括 GLM-5.3。扩大支持范围及在每个解码步骤执行检查仍在推进。[^1]

:::analysis
我们的解读是，KV 缓存页构成租户隔离边界：所有权与交接检查决定了解码端能够读取谁的数据。此次泄露源于推理服务流程，而非模型本身。长提示词之所以触发问题，是因为只有超过该部署 681,280 个 token 缓存池容量的请求，才会进入有缺陷的拒绝路径。[^1] 从可验证的角度看，这是运行层（runtime 层）的故障，而非模型层：泄露来自服务栈的交接环节，而非模型本身，因此信任一条回答不仅要信任模型，还要信任服务层的隔离是否成立。[^1]对用户而言，关键检查是版本与配置：确认自己的部署使用 Cloudflare 建议的 SGLang v0.5.22 或更高版本，并已落实其列出的缓存池容量检查；如果使用第三方服务，也应向服务方确认同样事项。[^1] 按本站的分层，这是一起 T2（软件与运行时）故障，而非 T3（模型与数据）问题——而 T2 所断言的正是关键：处理请求的正是这份代码和配置，因此当服务栈的版本与配置有记录、可核查时，用户就能判断自己的请求是否跑在受影响的部署上。[^1]
:::
:::checked
2026 年 10 月 28 日，我们阅读了 Cloudflare 的披露、SGLang v0.5.22 发布信息，以及 PR #36988 和 #38935。[^1][^2][^3][^4]
v0.5.22 发布说明未描述此次 KV 修复；未独立确认首个包含修复的版本。[^2]
未测试任何系统。
:::