Cloudflare 公開 GLM 5.3 快取資料曝露：為何 HTTP 200 仍可能回錯使用者內容？
Cloudflare 公開 GLM 5.3 Workers AI 跨請求快取資料曝露事件，155 筆回應受影響。解析記憶體容量與交接錯誤、已完成修復，以及自架 SGLang 團隊該檢查的版本與驗證方式。
呼叫 AI API 時，程式收到 HTTP 200，通常會把它當成成功回應。但如果回來的文字混入另一位使用者的內容，連線成功就無法回答資料是否安全。
Cloudflare 在 2026 年 10 月 26 日公開一宗 GLM 5.3 Workers AI 事故，問題發生在不同請求共用的運算記憶體，而非使用者主動分享對話。
依官方調查，8 月 27 日至 9 月 9 日間有 155 筆回應受影響，相關輸入都超過 681,280 個 token。服務已在 9 月 9 日修復恢復，10 月公布的是協調披露報告。
這個範圍很重要，因為事故只涉及指定模型與當時的推論配置，不能推成所有 Workers AI 模型都有相同問題。官方未發現蓄意利用的證據，也不等於能證明沒有任何人嘗試過。
我會把這份報告當成檢查推論服務交付品質的案例：對由供應商代管的服務確認影響與處置，對自架服務則核對容量、版本與輸出，不能只看請求有沒有報錯。
要理解為何一個成功回應仍可能帶出別人的文字，得先確認受影響的請求實際經過哪一道容量門檻。
Cloudflare 這次影響哪些請求？
這次曝露限於當時使用指定 GLM 5.3 模型、且輸入超過快取容量的請求。它是 Workers AI 提供的其中一個模型，服務識別名稱是 @cf/zai-org/glm-5.3，不代表所有模型都走同一套配置。
Cloudflare 的事故報告指出，問題從 8 月 27 日模型上線時存在，9 月 9 日完成修復。155 是受影響回應的筆數，受影響人數與文件數量則無法直接由這個數字得知。
相關輸入都超過 681,280 個 token。Token 是模型處理文字的計量單位，不能直接當成中文字數。這個門檻描述的是當時運算記憶體能容納的輸入規模。
這使事件有明確的判讀範圍。看到自己曾用過 Workers AI，還不能直接推定資料經過了這條路徑，必須同時核對模型、時間與請求長度。
官方排除自己的測試和研究者操作後，認為其餘請求的時間與數量符合一般長上下文使用，並表示沒有發現蓄意利用的證據。這是調查結果的表述，仍要和「已證明從未有人利用」區分。
而其他 Workers AI 模型沒有受這次問題影響，是因為它們相應的快取池比允許的上下文更大，請求走不到同一條異常路徑。這個原因比單純列出「不受影響」更有用途，因為配置改變時仍需要重新檢查。
受影響範圍之所以能用長度分開，源頭就是模型允許的輸入與實際可用記憶體沒有對齊。
容量不夠，為何沒有直接回傳錯誤？
模型宣告可接收的上下文，比負責處理輸入的快取池還大，拒絕請求又在機器交接時失效。前一個問題讓異常請求出現，後一個問題才讓舊資料混進回應。
輸入處理與文字生成分在不同機器
這套服務先由一組運算節點讀入使用者的輸入，再把中間結果交給另一組節點生成文字。前者稱為 prefill，後者稱為 decode，可以先理解成讀題與作答的分工。
為了接續兩段計算，中間結果保存在 KV 快取裡。它不是使用者可以點開的聊天紀錄，而是模型為了接續計算保存的資料。不同請求用過的記憶體頁面，完成後會交回共用池等待再利用。
頁面交給下一筆請求時，正常流程會以新資料覆寫。若負責交接的系統誤以為覆寫已經完成，後面的計算就可能讀到前一筆請求留下的內容。
快取池的大小也不是單獨填入的一個固定 token 設定。引擎啟動時，會從載入模型後剩餘的運算記憶體決定可用容量，所以模型宣告的上下文長度，和實際池子大小是兩個必須主動比對的數字。
這也是同一套引擎服務不同模型時，不能只沿用前一個模型檢查結果的原因。權重佔用的空間不同，即使機器沒有更換，剩下可保存中間結果的容量仍可能改變。
GLM 5.3 當時允許 1,048,576 個 token 的上下文，輸入端的快取池卻只能容納 681,280 個。超過容量的請求被引擎標成拒絕，原輸入換成只有一個 token 的替代內容。
交接成功，不代表完整內容已寫入
在單一節點中，這種替代內容可以讓批次流程結束，再把錯誤還給使用者。但分離部署的交接佇列只檢查請求是否完成，沒有正確識別等待回傳的拒絕狀態。
因此，輸入端仍計算了替代內容，傳出少量快取後通知生成端「交接完成」。生成端原先依長輸入預留的頁面，卻沒有全部被這次請求覆寫。
報告以八頁記憶體做圖解，說明第一頁換新、其餘仍留舊內容的情況。八頁是解說用的示意，真正問題是預留規模和實際傳送量不一致。
因此，修復不能只補一段輸入上限，還要讓所有接手的節點對拒絕狀態有同一個認知。
擴大快取與修正引擎，分別補哪一層？
公司同時調整記憶體配置與引擎拒絕路徑，讓正常請求放得下，異常請求也無法繼續交接。兩個措施處理的是不同失敗條件。
配置調整後，輸入端快取池約能容納 204 萬個 token，大於模型約 105 萬個 token 的上下文。如此一來，符合宣告輸入範圍的請求就不會因這個容量差走到拒絕路徑。
這次配置修正參照了同平台 GLM 5.2 的安排，釋出更多記憶體給輸入端使用。因此不能只把修復理解成換了一台更大的機器，重點是實際運作時能保存的資料量，必須涵蓋對外接受的輸入。
但只增加記憶體，仍把安全性綁在一組會變動的配置上。更換模型權重，也就是訓練完成後用於計算的核心參數，以及量化方式或平行運算設定，都可能改變載入模型後剩餘的記憶體。
所以引擎端也必須有防線。修正後，帶有待處理拒絕狀態的請求，會在開始建立交接、配置資源或搬移快取之前停止，保留原本應回傳的錯誤。
這使容量檢查和拒絕處理互相補位。前者減少正常請求碰到錯誤，後者則處理容量檢查失準或其他原因造成的拒絕，避免它被下一個節點當成正常工作。
官方用研究者的重現方式和帶有辨識標記的測試確認修正，再恢復服務。這是公司描述的驗證方法，本文沒有另外對公開服務進行測試。
兩層修復處理了已知入口，但原先的測試為什麼沒有看出錯誤，仍要回到驗證方法。
延伸閱讀：Cloudflare 加速 AI 代理沙盒：啟動、快照與恢復，決定任務能否接著做
驗收為何不能只看 HTTP 狀態碼？
這次預先測試看見成功狀態與串流輸出，卻沒有核對模型內容是否連貫、是否只屬於同一請求。表面上正常的回應，因而遮住了運算交接的錯誤。
HTTP 200 表示服務送回成功狀態，無法自行證明模型使用了正確輸入。同樣地，串流裡沒有錯誤訊息，只能說傳輸流程沒有以那種方式報錯。
公司承認上線前已知道容量差，卻從長上下文測試的成功回應推想引擎能妥善處理。報告將未檢查輸出與連貫性，列為測試的重要缺口。
測試要能辨認資料屬於誰
公司資安團隊後來使用兩個獨立帳號重現問題。這樣的設計是在驗證不同使用者之間的隔離，而不只是同一個帳號能不能連續問答。
辨識標記也有相同用途。測試應知道哪筆輸入放了什麼內容，才能判斷回應是否出現不該屬於它的資料，而不是只看答案讀起來是否流暢。
容量邊界兩側也要有不同的預期結果：範圍內應正確處理，超出可處理範圍應明確拒絕。若只確認兩種情況都收得到文字，反而會把本來應該失敗的請求當成服務穩定的證據。
對呼叫 API 的應用而言，這提醒團隊把成功分成兩件事：請求是否被服務接住，以及回傳內容是否符合原本工作。前者可以用狀態碼觀察，後者需要與任務相符的檢查。
當測試開始核對內容與請求歸屬，維運檢查也必須跟著每一次配置變更重新做。
自架 SGLang 要檢查哪些配置變動？
使用分離式輸入處理與生成節點的業者，要把快取容量和頁面生命週期納入部署檢查。這份報告的操作建議有特定架構前提，不能直接當成所有推論服務的共同設定。
報告建議相關業者使用 SGLang 0.5.22 或更新版本，或依自己的部署回補必要修正。最初阻止這次曝露的修正在 0.5.20 已出現，後面版本又加入提早拒絕與其他補強。
因此，查版本不是只比較一個大小符號。若團隊維護自己的分支，還要確認實際包含哪些修正，以及輸入處理和生成兩邊是否都使用了對應行為。
因此，容量應從引擎啟動紀錄或指標取得，再與上下文長度比較。更換權重、量化、平行方式或記憶體比例後，舊檢查結果不能自然沿用。
中斷也不能提早回收頁面
另一類風險來自跨機器搬移尚未完成，記憶體卻先被釋放給新請求。已送出的寫入若稍後才抵達，就可能覆蓋到下一筆工作的頁面。
延後釋放的機制，是等搬移排空或符合結束條件後再回收。公司也調整負載平衡器，避免客戶端斷線就在搬移途中觸發額外中止，減少需要跨節點協調的失敗路徑。
跨節點搬移還要限制單次傳送的批量，讓一次操作不會拖得比等待釋放的時限更久。否則一邊已把等待視為結束，另一邊仍有很長的寫入尾巴，兩台機器就可能再次對同一頁的可用狀態產生不同判斷。
這些檢查降低已知失敗的機會，後續的完整性驗證則是在錯誤發生時阻止它變成資料曝露。
完整性驗證下一步，哪些仍是研究？
公司正與 SGLang 改善快取交接與讀取時的歸屬驗證，目標是讓單筆錯誤在回傳資料前停止。這個方向需要分清已部署補強和仍在發展的設計。
交接時的校驗碼可以檢查傳送前後的資料是否一致，但它主要看的是交接這個時點。若頁面在之後被錯誤重用，仍需要更接近實際讀取位置的檢查。
公司曾為每個實體頁面加入會隨重新配置改變的標記，再讓請求保存它應該看到的標記。生成前比對，就有機會發現自己即將讀到不屬於這筆工作的記憶體。
這個原型在 GLM 5.2 測試中，對吞吐量與尾端延遲的影響都低於百分之一。尾端延遲是較慢一端請求的等待時間。但原型後來因可靠性問題停用，所以不能視為所有模型都已具備的完整解答。
報告也說明，現有校驗碼和偵測工具還沒有涵蓋每一種模型架構。形式方法與頁面歸零等工作仍在推進，不能因此宣稱類似錯誤已被數學證明不會再發生。
形式方法在這裡要處理的是跨機器狀態的一致性，例如雙方認為資料要寫到哪裡、有多大，以及何時才算完成。先建立協定模型，再追查實際系統偏離安全條件的位置，和只重跑一次成功測試有不同用途。
公司也承認證明工具能涵蓋的範圍會有缺口。這使長期改善需要同時保留工程檢查和監測，而不是等一個新機制出現後，就撤掉現有的容量與輸出驗證。
我認為最有用的改變，是把「有回應」往前推成「能確認回應屬於這筆工作」。使用代管 API 的團隊可以要求清楚的事故範圍與處置，自架團隊則要把這個問題放進每次部署的驗收。
對使用者而言，可追問的是服務如何確認每筆內容屬於自己。對業者而言，成功狀態只是這項確認的起點。
延伸閱讀：Cognition 漏洞修補外掛開源：從盤點到 PR，AI 升級執行環境還缺哪一步？
常見問題
所有 Cloudflare Workers AI 模型都有同樣問題嗎？
依 Cloudflare 調查，這次只影響指定 GLM 5.3 部署，其他模型的快取容量沒有觸發相同拒絕路徑。不能由一個事故推論全部模型受影響。
這是 10 月 26 日仍在發生的外洩嗎？
官方說明事故存在於 8 月 27 日至 9 月 9 日，9 月已修復恢復服務，10 月 26 日是協調公布研究與修補報告。
更新到建議版本，就能不做隔離測試嗎？
不能。版本修復與配置檢查處理不同條件，仍要核對實際部署、快取容量和輸出歸屬。官方也保留後續工具的架構支援限制。
