資料中心機櫃走道，兩側是一排排伺服器 — 示意圖，非 Cloudflare 機房。Carl Lender 攝，CC BY 2.0，Wikimedia Commons。

資安Cloudflare雲端 AI

Cloudflare 公布 Workers AI 外洩事件：GLM-5.3 模型 8/27 到 9/9 有 155 筆回應混進其他用戶的資料，自架 SGLang 的人建議升級到 v0.5.22 以上

趨勢新聞2026 年 10 月 28 日

AI 的回答裡夾著陌生人剛問過的內容，這件事在 Cloudflare 發生過。它 10 月 26 日（世界協調時間）公布：它的 Workers AI（開發者呼叫 AI 模型的雲端服務）上，Z.ai 公司的 GLM-5.3 模型從 8 月 27 日上線到 9 月 9 日修好之間，共有 155 筆回應含有其他用戶請求裡的資料，包括別人的提示詞（輸入給 AI 的文字）和部分生成內容。原因是 Cloudflare 的設定錯誤，加上開源推論引擎 SGLang（把模型跑起來回答問題的軟體）的程式錯誤。Cloudflare 說沒有發現蓄意利用，已經修補，並建議自架 SGLang 的業者升級到 v0.5.22 或更新版。本站的讀法：台灣企業用雲端 AI API 處理客戶資料或內部文件時，要知道多人共用 GPU 記憶體的服務，若引擎沒管好每段快取歸誰，就可能讓資料跨用戶外洩。

我會不會受影響？

只用 ChatGPT、Gemini 等聊天服務：報告只涉及 Workers AI 的 GLM-5.3，Cloudflare 說已確認 Workers AI 上其他模型沒有受影響。
8 月 27 日到 9 月 9 日用過 GLM-5.3（代號 @cf/zai-org/glm-5.3）：你送的內容可能出現在別人的回應裡。本站讀到的全文沒有寫是否個別通知受影響客戶，可以向 Cloudflare 詢問。
自架 SGLang，且用「預填／解碼拆分」模式：建議升級並檢查記憶體設定。

用影印機來想

本站的比喻：AI 服務的 GPU 記憶體像多人輪流用的影印機，被切成一頁一頁，前一個人用完不清空，下一個人直接蓋過去。這次系統以為新請求把每一頁都蓋掉了，其實只蓋了第一頁，後面幾頁還留著前人的內容，模型就照著這些頁面寫回答。Cloudflare 寫，頁面不歸零是推論引擎為了效能的常見做法，引擎要自己記清楚每頁屬於誰。

觸發條件很窄：只有超過 681,280 個 token 的提示詞才會出事。token 是模型切文字的單位；本站的讀法是這個長度遠超過一般對話，通常是一次丟進大量文件或程式碼才會到。Cloudflare 說，扣掉自家和研究員的測試，找到的請求「在時間與數量上符合一般長文本使用」（本站譯）。要分清楚的是：681,280 這個門檻指的是「收到異常回應」的那筆請求；被帶出的資料來自稍早送給同一模型的其他請求，原文沒有說那些請求也必須很長。

兩個錯誤怎麼疊在一起

第一個是設定。Cloudflare 讓 GLM-5.3 接受 1,048,576 個 token，但讀提示詞的那批 GPU 存放 KV 快取（模型讀完提示詞留下的計算紀錄）的空間只有 681,280 個。它上線前就知道兩者對不上，但以為引擎會回錯誤；它寫「我們只驗證了長上下文下的 HTTP 回應碼與引擎效能，沒有驗證模型輸出及其連貫性」（本站譯）。

第二個是 SGLang。Cloudflare 把工作拆給兩批 GPU：一批讀提示詞（預填），一批產生回答（解碼）。放不下的提示詞被判拒絕、換成一個 token 的佔位內容，請求卻沒被終止，預填端只傳一頁就回報「傳完了」。解碼端早就預留了整段長度的頁面，讀到其他頁上別人留下的資料，用戶收到的是正常回應而不是錯誤。單機部署時，這條路徑會正確回錯誤。

修補經過與給自架者的建議

資安公司 Knostic 研究員 Gadi Evron 9 月 8 日透過 HackerOne 通報。9 月 9 日（世界協調時間）13:22 宣告資安事件，14:00 模型下架，同日把空間調到約 204 萬個 token，並修補引擎讓被拒的請求在傳遞前就結束，19:40 恢復服務。修補最早在 v0.5.20，後續修正在 v0.5.21（10 月 2 日）與 v0.5.22（10 月 19 日）。

Cloudflare 建議拆分模式業者：每次改權重、量化、平行或記憶體設定後，從啟動紀錄比對每個預填與解碼節點的 KV 快取空間與上下文長度，空間小就調低上下文長度，不要靠前端代理擋，也不要假設引擎會拒絕放不下的請求；升級到 v0.5.22 以上；預填、解碼兩端都啟用延後釋放頁面，並限制 Mooncake 傳輸批次，讓單次傳輸不超過釋放逾時；模型支援時開 --disaggregation-enable-kv-checksum 與 --kv-canary 偵測毀損，再查紀錄確認請求真的有被驗證（原文說 GLM-5.3 等架構還在擴充支援中）；避免代理製造不必要的中止，Cloudflare 自己的做法是用戶端斷線後，預填連線保留到預填完成、解碼連線保留到第一個 token。本站的讀法：單機跑 SGLang 的，依原文碰不到這次的路徑。

原文 Cloudflare 部落格〈Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang〉（Kevin Flansburg、Michelle Chen，2026-10-26），受影響期間、155 筆、681,280 與 1,048,576 個 token、成因、時間表、SGLang 版本與給業者的建議都取自此文；引號內文字為本站譯。Cloudflare 文中提到 SGLang 團隊另有同步說明，本文未引用。