GLM-5.3 Workers AIモデルにおけるクロスリクエストKVキャッシュの露出とそのSGLangによる修正

Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang

2026年9月8日、Knostic社のセキュリティ研究者Gadi Evron氏から、2026年8月27日から影響が出ていたGLM-5.3 Workers AIモデル（@cf/zai-org/glm-5.3）のテナント分離に関する問題について通知を受けました。この問題を修正し、9月9日にモデルを復旧しました。Workers AIでホストされている他のモデルは影響を受けていないことを確認しています。

2026年8月27日から9月9日の間に、GLM 5.3 Workers AIモデルを使用した少数の顧客が、それより前に同じモデルに送信された他の顧客のリクエストからのデータを含む応答を受け取りました。合計で155件の応答が影響を受けましたが、すべて681,280トークンを超えるプロンプトに対するものでした。

当社自身のテストと研究者のテストを除外すると、特定されたリクエストは、バグを繰り返し悪用しようとしたものではなく、通常の長文コンテキストの使用とタイミングおよびボリュームが一致していました。悪意のある悪用の証拠は見つかっていません。

本日、オープンソース推論エンジンであるSGLangからの投稿と合わせて、このレポートを公開します。この投稿では、問題を引き起こしたバグ、当社の対応タイムライン、および本番環境のSGLangデプロイメントに対するその後の強化策について説明します。また、このバグおよび類似のバグに対処するためのSGLangのアップストリームメンテナーとの継続的な取り組みについても詳述します。

What happened

GLMはZ.ai製のテキスト生成モデルで、エージェント型コーディングワークフロー向けに構築されており、Workers AIで利用可能な多くのモデルの1つです。Gadi Evron氏は9月8日、HackerOneプログラムを通じて、Workers AIの@cf/zai-org/glm-5.3に送信された非常に長いプロンプトが、他のユーザーのセッションのテキストを返すことがあるという報告を提出しました。Cloudflareは翌朝問題を再現し、インシデントを宣言してから40分以内にモデルをオフラインにしました。その後、修正された設定とパッチ適用済みの推論エンジンをデプロイし、同日にサービスを復旧しました。

このクロスリクエストKVキャッシュ露出の特定の報告は、2つの重複する問題の結果でした。1つ目は、Cloudflareが使用しているオープンソース推論エンジンSGLangの設定ミスでした。GLM 5.3を1,048,576トークンのコンテキストウィンドウでデプロイしましたが、プリフィルGPUのKVキャッシュプールには681,280トークンしか収容できませんでした。この不一致はローンチ前に認識していました。エンジンが処理できないプロンプトに対してエラーを返すことを期待しており、長文コンテキストテストでは成功した応答が得られたため、これを問題とは考えていませんでした。

2つ目は、SGLangが分離モード（disaggregated prefill/decode mode）で結果として生じるオーバーレングスリクエストをどのように処理したかのバグでした。プールに収まらないプロンプトは内部的に拒否とマークされ、1トークンプレースホルダーに置き換えられましたが、リクエストを中止してクライアントエラーを返す代わりに、プリフィルはプレースホルダープロンプトのKVキャッシュを生成し、それをデコードノードに転送しました。デコードノードは「転送完了」メッセージを受け取り、プリフィルが前のリクエストのKVキャッシュをこのリクエストのフルプロンプトで上書きしたと想定しましたが、実際には前の状態の大部分がそのまま残っていました。デコードノードはその後、以前のリクエストのデータがまだ保持されている古いキャッシュページをアテンドしながら応答を生成しました。その結果、681,280トークンを超えるプロンプトへの応答には、他のユーザーのGLM 5.3セッションからのデータが含まれる可能性がありました。

Immediate remediation

モデルを無効にした後、公開アクセスを復旧する前に、この脆弱性を修正するために以下の措置を講じました。

設定を修正するため、プールにフルコンテキストを保持するようにしました。 GLM 5.3の設定をGLM 5.2の設定に合わせるように調整しました。これにより十分なGPUメモリが解放され、プリフィルKVプールは現在約204万トークンを保持できるようになり、1,048,576トークンのコンテキスト長のおよそ2倍になりました。コンテキストウィンドウに収まるプロンプトは常にプールにも収まるようになったため、有効なリクエストでは拒否パスに到達することはありません。これだけでバグが発生するのを防ぐことができます。

エンジンを修正するため、拒否パスも安全にしました。 プールサイズだけに依存するのは脆弱です。量子化、テンソル並列処理、CUDAグラフサイズ、または将来のモデルバージョンのいずれかの変更は、見落としやすい方法でプールサイズを変更します。さらに、プリフィルスケジューラがリクエストを拒否して同じバグをトリガーする可能性のある他の状況も存在する可能性があります。これを防ぐために、エンジンにパッチを適用し、保留中の拒否を伴うリクエストは、ブートストラップ、割り当て、またはKV転送が行われる前に、元のエラーとともに分離アドミッションキューでリタイアされるようにしました。これをアップストリームに#38704として提案しました。これには、デコードノードが転送されたトークン数が予約された数と一致するかどうかを確認する機能も含まれていました。この修正は、関連する障害パスのために9月6日にマージされたSGLang mainの#36988に既に含まれていましたが、まだリリースされていませんでした。メンテナーは、当社の方法論に従ってこれらのリクエストをより早く拒否する#38935もマージしました。

モデルを復旧する前に、これらの変更の両方を研究者の再現スクリプトと当社のカナリアマーカテストに対して検証しました。

Background: how we serve GLM 5.3

Workers AIは、分離構成でSGLangを使用してGLM 5.3を実行しています。プリフィルGPUのプールがプロンプトを処理し、そのためのモデルのKVキャッシュを生成し、次にそのキャッシュをリモートダイレクトメモリアクセス（RDMA）経由でMooncakeを介してデコードGPUのプールに渡し、応答を生成します。以前の投稿で、このアーキテクチャについて高性能LLMやより小さく、より速く、より安全なモデルについて説明しました。

GPUメモリ内のKVキャッシュは、固定サイズのページを共有するプールです。各リクエストは、アドミッション時にページが割り当てられ、完了時に解放されます。ページは現在、リクエスト間でゼロクリアされていません。次にページを取得するリクエストは、それを上書きするだけです。このアプローチは推論エンジンで一般的であり、最高のパフォーマンスを達成するために必要ですが、推論エンジンがこれらのメモリページの所有権を追跡する責任を負うことを意味します。KVキャッシュページの所有権とライフタイム追跡は、単一ノード内での共有所有権（KVキャッシュオフロードとトークン生成の両方が異なるライフタイムでメモリにアクセスします）だけでなく、リモートプリフィルノードと技術的に共有される所有権（プリフィルノードはページへの同時ミュータブル参照を保持します）も処理する必要があります。

さらに、このプールのサイズは設定値ではありません。SGLangは、モデルウェイトのロード後に残ったGPUメモリから起動時にサイズを決定します。モデルの広告されたコンテキスト長は、個別の設定値です。両者を一致させる強制力はなく、確認するのは私たちの仕事です。

Issue one: misconfiguration

当社のGLM 5.3プリフィルノードでは、設定によりプールが681,280トークンになったのに対し、モデルのコンテキスト長は1,048,576トークンでした。選択されたKVプールサイズは、起動時のSGLangログに印刷され、メトリックとして公開されます。このサイズ不一致は認識していましたが、ローンチ前のテスト中に、ベンチマーク中にエラーフレームのない成功したHTTPステータスコードとストリーミングボディを観測しました。エンジンがストリーミングやその他のメカニズムを通じて、KVキャッシュプールと要求されたコンテキストウィンドウの違いを正常に処理できると想定していました。

これはテストにおける重要なギャップの1つでした。長文コンテキストでのHTTP応答コードとエンジンパフォーマンスのみを検証し、モデルの出力と一貫性は検証しませんでした。現在、デプロイメントの変更が本番環境に適用される前に、応答コードから推測するのではなく、実行中のエンジンからKVプールサイズをコンテキスト長と直接比較してチェックしています。

Issue two: SGLang bug

v0.5.21で、SGLangチームはKVプールサイズを超えるプロンプトの処理方法におけるこのバグに対処しました。以前は次のようなことが起こっていました。

KVプールに収まらないプロンプトが到着すると、SGLangのスケジューラはそれを拒否しました。拒否パス（Req.set_finish_with_abort）は、クライアントに返すエラーを記録し、プロンプトを1トークンプレースホルダーにスワップして、リクエストが実際のメモリを割り当てることなく通常のバッチ処理を通過できるようにしました。単一ノードデプロイメントではこれは機能しました。プレースホルダーが実行され、バッチが完了し、クライアントはエラーを受け取りました。

［画像］

当社が運用するような分離モードでは、プリフィルとデコードの両方のアドミッションキューは、リクエストが完了したかどうかをチェックしており、拒否されたかどうかはチェックしていませんでした。拒否されたリクエストは、自身をライブと報告しました。したがって：

1. ブートストラップ。 ルーターはデコードノードにプロンプト長（図では8ページ）を通知しました。デコードはリクエストのために8つのKVページを予約しました。
2. プリフィルアドミッション。 プリフィルアドミッションキューは、req.finished()がFalseのリクエストをアドミッションしました。拒否されたリクエストは、finished_reasonではなくto_finishに拒否を格納したため、finished()は依然としてFalseを返しました。拒否されたリクエストはアドミッションされました。
3. プリフィルフォワードパス。 拒否により、プロンプトは既に1トークンプレースホルダーに置き換えられていました。プリフィルは、その1トークンに対して単純なフォワードパスを実行しました。
4. KV転送。 プリフィルは1ページのKVをデコードに送信し、転送が完了したことを通知しました。
5. デコードアドミッション。 デコードのアドミッションキューも同じfinished()チェックを持っていたため、ハンドオフを受け入れました。
6. デコードアテンション。 デコードは生成を開始し、アテンションは予約された8ページすべてを読み取りました。このリクエストによって書き込まれたのはページP0のみでした。ページP1からP7には、以前のリクエストが残したものが保持されていました。他のユーザーのプロンプトと部分的な生成物です。
7. 応答。 クライアントはHTTP 400ではなくHTTP 200を受け取りました。prompt_tokensは長いプロンプトと一致し、応答は一貫していました。8ページ分のプリフィルにかかる時間よりも速く到着し、他のユーザーのKVページからのコンテンツが含まれていました。

しきい値を超えるすべてのリクエストがこのようになりました。このバグは、Cloudflareがこのインシデントを調査中に発見した、別のユーザーによって7月6日（2026年）にSGLangに問題#30233として報告されていました。当社はv0.5.10以来、SGLangとこれらの種類の問題をフラグ立てしていましたが、このセキュリティインシデントにより、Cloudflareが既にSGLangチームと協力して開始していた作業が加速されました。この問題のパッチは、SGLang v0.5.20でリリースされ、v0.5.21およびv0.5.22でフォローアップされ、SGLangに依存する他のすべてのオペレーターが利用可能です。SGLangの依存関係をv0.5.22以降に更新することを強くお勧めします。特定のPRの詳細については、以下をお読みください。

GLM 5.3のみがこのバグの影響を受けました。Workers AI上の他のすべての分離デプロイメントでは、プリフィルとデコードの両方でKVプールがコンテキスト長よりも大きいため、拒否パスに到達するリクエストはありませんでした。エンジン修正と以下の強化策を、当社が提供するすべてのモデルに適用し、デプロイメントチェックは新しいデプロイメントごとにそれらを要求します。

Timeline

すべての時間はUTC。

Ongoing hardening effort

このバグは、Cloudflareが数ヶ月間取り組んできたKVキャッシュメモリ安全性バグのクラスに属します。各ケースで、ページが解放され、再利用され、または他の何かがまだそれに権利を持っている間に読み取られます。私たちは2つの一般的な原因を見ています。

1つ目は、単一ノード内でのページライフタイムです。デコードノード上のいくつかのタスクが同時に同じページを保持できます。トークン生成、ホストメモリへのオフロード、KV転送受信者、およびアボートおよびエラーパスです。それらのうちの1つが、他のものがまだ使用している間にページを解放すると、新しいリクエストがそのページを使用している間にそのページが新しいリクエストに与えられる可能性があります。デコードオフロード（#24226、#30899）および文法エラー時の二重解放（#30937）に対する以前の修正はこの種のものでした。

2つ目は、ノード間の競合です。プリフィルがまだKVキャッシュをデコードにRDMA経由で書き込んでいる間にリクエストがアボートされると、既に送信された書き込みは取り消せません。デコードがそれらのページをすぐに解放すると、それらのページが別​​のリクエストに与えられ、遅延した書き込みがそのリクエストのKVキャッシュに着弾します。Cloudflareは、提案された修正（#31357、#38961）と再現スクリプト（#32564）を通じて、この競合を修正する取り組みに貢献しました。どちらの場合も結果は出力の破損、またはエラーが発生しないまま他のユーザーのデータが他のユーザーの応答に含まれることでした。このインシデントのバグは異なっていました。拒否されたリクエストが毎回ハンドオフを通過したのではなく、タイミングの偶然によるものでした。しかし、結果は同じでした。プリフィルがリクエストを拒否し、デコードがそれに気づかなかったという、デコードがこのリクエストが書き込まなかったページを読み取るというものです。これらのいずれも、プリフィルがリクエストを拒否し、デコードがそれを知らなかったこのインシデントの障害をカバーしていませんでした。

インシデント以来、私たちは以下を行いました。

• 遅延リリースを拡張して、プリフィルのソースページも保持し、アボートだけでなくすべての障害タイプをカバーするようにしました。これをアップストリームに#38961として提案しました。これは#40645、#41402、および#41404に置き換えられました。
• バウンドされたMooncake転送バッチ（#32758、SGLangコミュニティから）をデプロイしました。これにより、単一の転送呼び出しが解放タイムアウトを超えることがなくなりました。
• ロードバランサーを変更し、クライアント切断が転送中にリクエストをアボートしなくなりました。プリフィルが完了するまでプリフィル接続を保持し、最初のトークンまでデコード接続を保持してから、両方を閉じます。
• すべての分離デプロイメント変更にチェックを追加しました。KVプールサイズとコンテキスト長の比較、両方の役割での遅延リリース、解放タイムアウト内の転送バッチ境界、および必要なすべてのパッチの適用。

これらの変更はすべて、分離本番環境デプロイメントにリリースされました。

Working with the SGLang team

9月10日、インシデントの翌日に、SGLangメンテナーとRadixArkで会合しました。RadixArkが競合状態の報告を調査し、整合性チェックのアイデアをアップストリームし、このクラスのバグの再現テストを構築することに合意しました。

以下のものがSGLang mainにマージされ、このインシデントおよび関連するKVキャッシュ競合状態に対処しており、1つを除いてすべてv0.5.22に含まれています。分離SGLangを実行しているオペレーターは、v0.5.22に更新するか、必要に応じてこれらのパッチをバックポートすることを推奨します。

これらのフォローアップはまだ作業中です。

• #39729 --disaggregation-enable-kv-checksumの追加クリーンアップ。マージ済み、リリース待ち。
• ページ解放時のKVゼロクリア、ドラフト提案：#46435
• KVチェックサム検証をプリフィルからデコードへのハンドオフからすべてのデコードステップに拡張（「Integrity by construction」参照）。
• より広範なKVカナリアおよびKVチェックサムモデルと機能サポート

What we recommend to other operators

SGLangを分離プリフィル/デコードモードで実行している場合は、以下を推奨します。

1. KVプールを測定し、コンテキスト長と比較してください。 すべてのプリフィルおよびデコードノードで、エンジンの起動ログから、ウェイト、量子化、並列処理、またはメモリフラクションの変更ごとに測定してください。プールが小さい場合は、コンテキスト長をそれに合わせて短くしてください。制限を強制するためにプロキシに依存せず、エンジンが収まらないものを拒否すると想定しないでください。これは、当社が実施しなかったチェックです。
2. #36988および#38935（v0.5.22以降）を含むビルドにアップグレードしてください。 これにより、プールサイズに関係なく、オーバーレングスリクエストはハンドオフ前に拒否されます。これはエンジン側の修正であり、ステップ1のチェックが間違っていた日のバックストップとなります。
3. 両方の役割で遅延KVリリースを有効にして実行してください（#41023以降デフォルト）、およびMooncake転送バッチをバインドして、単一のタイムアウトした呼び出しが未完了の書き込みの無制限のテールを残さないようにしてください。
4. モデルがサポートしている場所で破損検出を有効にしてください。 --disaggregation-enable-kv-checksumおよび--kv-canaryは、まだすべてのモデルアーキテクチャをカバーしていません。ログを確認して、リクエストが検証されていることを確認してください。CloudflareはSGLangチームと協力して、GLM 5.3、GLM 5.3 Flash、DeepSeek V4を含む、より多くのアーキテクチャに両方のチェックを拡張しています。
5. プロキシが不要なアボートを生成していないことを確認してください。 ロードバランサーを設定して、リクエストが最初のトークンまで続行できるようにし、クロスノードの調整が必要なアボートをトリガーしないようにしてください。

Longer term

Integrity by construction

設定チェックとライフサイクル修正は、ページが悪用される可能性のある方法を減らします。それらは悪用を不可能にするわけではなく、このインシデントは、次のバグがまだ見ていない形状になるときの注意喚起です。永続的な解決策は、エンジンが読み取り時に、リクエストが所有していないページをアテンドしようとしていることを検出し、そのリクエストのみを失敗させることで、他人のデータを返すのではなく、問題を解決することです。

当社は夏にこのプロトタイプを構築し、8月に説明しました。各物理KVページには、ページが再割り当てされたときに変化するタグがあり、各リクエストは期待するタグを記録し、デコードがキャッシュを読み取る前にマッピングがチェックされます。当社のテストでは、スループットとテールレイテンシで1%未満のコストでした。8月中旬にGLM 5.2でテストしましたが、信頼性の問題によりすぐに無効にしました。

プロトタイプは特定の注意バックエンドとモデルアーキテクチャにも結びついていたため、一般的な修正にはなりませんでした。Cloudflare固有のパッチを維持するのではなく、モデル全体で機能する本番バージョンをエンジンに組み込むために、SGLangチームと協力しています。#39500の転送ごとのチェックサムは最初のステップです。これはプリフィルからデコードへのハンドオフを検証します。ページレベルのタグは、キャッシュの読み取り後も、すべての読み取りをチェックするため、さらに進んでいます。

Integrity by mathematical impossibility

RDMAは、一方のノードのメモリからもう一方のノードのメモリに直接データをコピーします。2つのマシンがデータの送信先、サイズ、および完了時期について合意することが不可欠です。不一致があると、受信者は間違ったデータを読み取る可能性があります。このバグは、分散システムにおける一貫性の失敗の例であり、2つのマシンがそのシステムの状態について不整合なビューを持っていました。

Cloudflareの他の場所では、形式検証手法を使用して分散システムの安全性を証明することに力を入れています。Topazは、権威DNSサーバーの競合のないIP選択を可能にします。MeerkatのQuePaxa実装のモデルは、その後修正された一貫性のバグを実証しました。

現在、形式手法の経験をKVキャッシュ転送エンジンに振り向けています。これは、RDMAベースのKVキャッシュ転送プロトコルの安全性をモデル化し、証明することから始まります。目標は、Mooncakeを使用して本番環境のSGLangの分散KVキャッシュシステムをモデル化し、保証したい安全プロパティからの逸脱を追跡して修正することです。目標は、この種のバグが二度と発生しないことを、可能な限り証明することです。現実的には、プロバーが私たちに伝えることができるものにはギャップがあると予想されますが、システムの残りの部分を証明することで、それらのギャップをより密接にレビューおよび監視できます。

Coordinated disclosure

このレポートは、協調開示の一環として公開しています。報告者であるGadi Evron氏に感謝します。彼は明確で再現可能なスクリプトでHackerOneプログラムを通じて問題を報告し、公開前に修正し、SGLangメンテナーと調整する時間を与えてくれました。また、RadixArkのSGLangチームにも感謝します。彼らはこの問題を私たちと同じように自分たちの問題として扱い、緊急にアップストリーム修正をマージしました。

SGLangチームからの投稿でさらに読むことができます。

Workers AIでセキュリティ上の問題を見つけた場合は、hackerone.com/cloudflareで報告してください。