Cloudflare 於 2026 年 10 月 26 日與 SGLang 同步公開一宗事故報告。Workers AI 上的 GLM-5.3 模型（@cf/zai-org/glm-5.3）在 2026 年 8 月 27 日至 9 月 9 日期間，出現跨租戶的 KV cache 洩漏，少數客戶收到包含其他客戶請求內容的回饋。
事件概要
官方指出，事件由安全研究員 Gadi Evron（Knostic）於 9 月 8 日透過 HackerOne 通報；Cloudflare 於隔日重現問題，並在宣布事故後 40 分鐘內將模型下線，同日部署修正配置與修補版推理引擎，於當日恢復服務。官方確認只有 GLM-5.3 受影響，其他 Workers AI 模型不受影響。官方統計：共 155 個回饋受影響，全部來自超過 681,280 token 的提示。排除自家測試與研究員的請求後，這些請求在時間與數量上與一般長上下文使用一致，沒有發現有惡意利用漏洞的證據。
兩個問題雙重加
官方將成因歸咎為兩個重疊的問題：
一、配置失誤。 Cloudflare 以 1,048,576 token 的上下文窗口部署 GLM 5.3，但 prefill GPU 的 KV cache 池只有 681,280 token 的容量。官方事前知道這個不匹配，但預期引擎會對無法處理的提示回傳錯誤，而長上下文測試又回傳成功回饋，因為未視之為問題。官方承認這是測試上的關鍵缺口：他們只測試了 HTTP 狀態碼與引擎效能，沒有測試模型輸出的內容與連貫性。
二、SGLang 的錯誤處理缺陷。 在分離式 prefill/decode 模式下，超過池容量的提示會被內部標記為拒絕，並以一個 token 的佔位提示取代；但引擎沒有中斷請求並回傳客戶端錯誤，而是為佔位提示生成 KV cache 並傳送到 decode 階段。decode 階段收到「傳輸完成」信息後，以為 prefill 已用完整個提示覆蓋 KV cache，實際上大部分狀態仍保留，於是 decode 在生成時讀到殘載有其他用戶資料的過期快取頁。官方指出，在單節點部署下這個拒絕路徑運作正常（客戶端會收到錯誤）；問題只在分離式部署出現，因為雙邊的準入隊列檢查的是請求是否「完成」，而非是否「被拒絕」。
修正與上游
Cloudflare 的即時修正包含：
- 讓池容量覆蓋完整上下文：調整 GLM 5.3 配置至與 GLM 5.2 一致，令 prefill KV 池可容納約 204 萬 token，約為上下文長度的兩倍，令合法請求永不觸發拒絕路徑
- 修補引擎的拒絕路徑：讓帶有拒絕標記的請求在 disaggregation 準入隊列中以原始錯誤結束，之後才進行 bootstrap、分配或 KV 傳輸；並在 decode 端驗證傳輸的 token 數量與預留數量一致
- 兩項改動都以研究員的重現腳本與自家 canary 測試驗證後才恢復服務
官方亦將修正提交上游（PR #38704），並指 SGLang 已在 #36988（9 月 6 日合併）、#38935 等相關修正；相關修補在 SGLang v0.5.20 發布，並在 v0.5.21、v0.5.22 跟進，官方強烈建議所有 SGLang 用戶升級至 v0.5.22 或之後。
為何值得業界注意
官方指出，這屬於一類 KV cache 記憶體安全問題：頁面在仍被使用時被釋放、重用或讀取。原因之一是同一節點內的頁面生命週期（生成、卸載到主機記憶體、傳輸接收、中斷與錯誤路徑同時持有同一頁），之二是跨節點的競態（請求中止時 prefill 仍透過 RDMA 瀰入，已送出的瀰入無法收回）。官方過去幾月已就此類問題與 SGLang 合作，並已把引擎修正與加固用到所有以 SGLang 服務的模型，新增部署亦必須通過相關檢查。
參考資料
[1] Cloudflare 官方部落格 — Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang (2026 年 10 月 26 日)
[2] SGLang 官方儲存庫