Cloudflare 於二零二六年十月二十六日在官方網誌發布協調披露，指 Workers AI 上的 GLM-5.3 自八月二十七日起存在跨請求鍵值（KV）快取隔離缺陷，直至九月九日修復並恢復服務；期間共一百五十五則回應受影響，且皆屬超過六十八萬一千二百八十個詞元的超長提示。來源真實性已核對 Cloudflare 官方事故報告，並與開源推理引擎 SGLang 團隊協調公開。
Cloudflare／官方：Workers AI 上 GLM-5.3 跨請求 KV 快取外洩——一百五十五則長提示回應受影響；與 SGLang 協調披露並建議升級至 v0.5.22
引言
共享推理叢集若把「模型能力」與「租戶隔離」分開理解，風險往往出在快取與排程邊界，而非模型權重本身。Cloudflare 這次公開指出：在拆分 prefill／decode 的 SGLang 部署中，當鍵值快取池小於模型標稱上下文長度，被拒絕的超長請求仍可能把殘留頁面交給解碼節點，使後續回應讀到其他用戶的提示與部分生成內容。本文已核對 Cloudflare Blog 完整時序與技術說明，來源真實性已驗證；重點在多租戶 AI 推理的記憶體頁面所有權，而非個別模型能力評測。
一、核心事件：GLM-5.3 跨請求 KV 快取暴露與同日修復
按 Cloudflare 官方報告，安全研究員 Gadi Evron（Knostic）於九月八日經 HackerOne 通報：向 Workers AI 的 @cf/zai-org/glm-5.3 送出極長提示時，回應偶爾夾帶其他用戶工作階段的文字。暴露窗口自二零二六年八月二十七日（該模型上線日）至九月九日；公司確認僅此模型受影響，Workers AI 上其他模型未見同類問題。
可核對影響範圍如下：
- 受影響回應共 一百五十五則；
- 全部對應提示長度 超過 681,280 個詞元；
- 剔除 Cloudflare 自身測試與研究員操作後，時序與量級符合一般長上下文使用，未發現刻意重複利用的證據。
應變節奏方面：九月九日早上開始核實，當日約十三時二十二分（協調世界時）宣布資安事故，約二十五分鐘內以兩個獨立帳戶重現外洩；約十四時將模型改為私有（請求回傳 HTTP 400），並更新狀態頁；同日十四時五十二分起將 prefill 節點滾動至修正配置，十九時四十分左右在套用引擎修補並通過研究員重現腳本與金絲雀測試後恢復公開。十月二十六日與研究員、SGLang（RadixArk）維護方作協調披露。
二、技術原理：上下文長度與 KV 池錯配，疊加拆分推理拒絕路徑缺陷
1. Workers AI 如何服務 GLM-5.3
Workers AI 以開源推理引擎 SGLang 採拆分（disaggregated）架構運行 GLM-5.3：一組 prefill GPU 處理提示並產生鍵值快取，再經 Mooncake 以遠端直接記憶體存取（RDMA）交給 decode GPU 生成回應。GPU 記憶體中的 KV 快取是固定大小頁面池；請求入場時分配頁面、結束時釋放。頁面在請求之間不會先清零，下一個請求覆寫即可——此為推論引擎常見效能取捨，因此頁面所有權與生命週期追蹤必須正確。
2. 問題一：配置錯配
Cloudflare 為 GLM-5.3 配置 1,048,576 詞元上下文窗口，但 prefill GPU 上的 KV 快取池實際只夠約 681,280 詞元。團隊上線前已知此差距，並假設引擎會對放不下的提示回傳錯誤；長上下文測試卻常看到成功 HTTP 狀態與串流回應，因而未把「輸出內容是否屬於本請求」納入驗證。官方其後承認測試缺口：只驗狀態碼與效能，未驗輸出一致性。
3. 問題二：SGLang 拒絕路徑在拆分模式下失效
當提示長於 KV 池，調度器會標記拒絕，並把提示換成單詞元佔位符以便走完批次管線。在單節點部署，客戶端通常仍能收到錯誤；但在拆分模式下，prefill 與 decode 入場佇列當時檢查的是請求是否「已完成」，而非是否「已拒絕」。被拒絕的請求仍被當成活請求：prefill 只為佔位符產生極少快取並宣告傳輸完成，decode 卻已按原長提示預留多頁，於是在多數仍屬舊用戶殘留的頁面上做注意力計算，最終回傳 HTTP 200，且內容可能混入他人資料。
4. 修復與對其他營運者的建議
即時修復包括兩層：把 prefill KV 池擴大至約 二百零四萬詞元（約為上下文長度兩倍），使合法請求不再走拒絕路徑；並修補引擎，使帶待決拒絕的請求在入場佇列階段即以原錯誤結束，避免任何 bootstrap、配置或 KV 傳輸。相關修復已進入上游（例如 #36988、#38935 等），並隨 SGLang v0.5.20／v0.5.21／v0.5.22 發布。Cloudflare 強烈建議所有依賴 SGLang 的營運者升級至 v0.5.22 或更新，並在每次權重、量化、並行或記憶體比例變更後，直接以引擎啟動日誌比對 KV 池大小與上下文長度，不可假設代理層或狀態碼會自動擋下錯配。
四、日常應用場景
1. 開發者與技術團隊
若自建或託管拆分 prefill／decode 推論，應把「上下文上限」寫進部署檢查清單，並與實際 KV 池度量綁定；長上下文代理、程式碼庫問答與文件擷取尤需驗證輸出是否只來自本請求，而非只看延遲與吞吐量。升級 SGLang、開啟可用的 KV checksum／canary，以及避免負載平衡器在傳輸中途濫發中止，皆屬官方點名的操作建議。
2. 企業與隱私敏感行業
金融、醫療、法律與政府相關工作負載若共用同一公開或多租戶模型端點，跨請求快取外洩等於提示與中間狀態可能被其他租戶「讀到」。採購合約宜要求供應商披露隔離架構、事故通報時限與長上下文測試方法；對高度敏感資料，更穩妥做法是私有部署或嚴格租戶隔離的專用實例，並限制可送出的上下文長度。
3. 一般用戶
一般對話用戶未必觸及超過六十八萬詞元的提示，但企業把整本程式庫或長文件一次塞進共享端點時，正是此類缺陷的暴露條件。選用雲端 AI 服務時，除看模型名稱，也應留意供應商是否公開多租戶推理的記憶體隔離說明與歷史事故報告。
4. 香港與亞洲市場視角
香港金融、專業服務與初創普遍把程式碼助手、知識庫問答與客服代理接到雲端 API。本案說明：開源引擎配置與多節點快取傳輸同樣屬於雲端與網絡安全邊界，不能假設「用了大廠 Workers／GPU 叢集就自動租戶隔離」。本地團隊評估供應商或自建 GPU 推論時，應把 KV 池／上下文稽核、版本釘選與事故演練寫進上線門檻；若資料不可出境或不可與其他租戶共池，宜優先考慮可控環境中的私有模型與網絡分段。
五、專業評價與潛在考量
優勢
- 官方報告提供可核對的時間線、受影響回應數量、詞元門檻、根因雙因素與上游修補版本，透明度高。
- 協調披露同步推動 SGLang 社群修復，讓其他採同一引擎的營運者可直接升級，而非只作單一雲端個案。
- 明確區分「配置錯配」與「引擎拒絕路徑缺陷」，並承認測試只看 HTTP 成功碼的方法論缺口，對同行具操作參考價值。
需要留意的地方
- 暴露窗口自模型上線日起算約兩週，顯示長上下文路徑的隔離測試不足；其他平台若有類似拆分架構，不宜假設「未見報道即無風險」。
- 一百五十五則受影響回應屬 Cloudflare 盤點結果；客戶端若未保留日誌，難自行還原當時外洩片段。
- 官方稱未發現刻意利用，並不排除未被觀測到的探測；企業仍應按事故等級檢視當期送入該模型的敏感提示。
- 後續「按頁標記／形式化驗證 KV 傳輸」仍屬進行中方向，短期仍須依賴配置稽核、引擎版本與可觀測性。
整體而言，這是針對多租戶 AI 推理記憶體隔離的可核對官方事故披露，焦點應放在 KV 快取頁面所有權與拆分推理拒絕路徑，而非解讀為某一開源模型權重本身遭後門植入。
結語
Cloudflare 公開 Workers AI 上 GLM-5.3 的跨請求 KV 快取外洩：一百五十五則超長提示回應受影響，根因是上下文長度與 KV 池錯配疊加 SGLang 拆分模式拒絕路徑缺陷，已於九月九日修復並於十月二十六日與上游協調披露，同時建議營運者升級至 SGLang v0.5.22 或更新。對香港企業而言，共用推理端點的真正風險往往在快取與排程邊界；若要把關鍵程式碼、客戶資料與行業知識留在可控架構，並同時強化雲端與網絡邊界，可參考 YSK Limited 的雲端遷移與網絡安全方案：https://ysk.hk/services/cloud-security
參考來源
- Cloudflare Blog（協調披露，2026-10-26）：Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang — https://blog.cloudflare.com/kv-cache-exposure-remediation/
- SGLang 專案（上游修補與版本，見 Cloudflare 報告引述之 PR／v0.5.20–v0.5.22）：https://github.com/sgl-project/sglang