Cloudflare、GLM 5.3で155件の応答に他テナントのデータ混入

何が公表されたのか

Cloudflareは2026年10月26日、同社のWorkers AIで提供するGLM 5.3モデル(@cf/zai-org/glm-5.3)でテナント分離の問題が発生していたと公表しました。発端は2026年9月8日、Knosticのセキュリティ研究者であるGadi Evron氏がHackerOne経由で報告したことです。問題自体は2026年8月27日から発生していたとされています。Cloudflareは翌朝に問題を再現し、インシデントを宣言してから40分以内にモデルをオフラインにしました。

影響は、このモデルに長いプロンプトを送った一部の利用者に対し、直前に同じモデルへ送られた別の利用者のリクエストに由来するデータを含む応答が返ったというものです。該当した応答は合計155件で、いずれも681,280トークンを超えるプロンプトに対するものでした。Cloudflareは自社のテストと研究者の検証分を除いたうえで、時刻と件数が通常の長文コンテキスト利用と整合しており、繰り返し悪用された形跡はないとしています。

Cloudflareは意図的な悪用の証拠は見つかっていないと明言し、Workers AIでホストする他のモデルには影響が及んでいないことを確認したとしています。モデルは修正後の2026年9月9日に公開へ戻されました。今回はSGLangの上流メンテナーと協調した開示として、SGLang側の投稿とあわせて公開されています。

原因となった2つの問題

1つ目はCloudflare側の設定ミスです。GLM 5.3は1,048,576トークンのコンテキスト窓で展開されましたが、prefill用GPUのKVキャッシュプールは681,280トークン分しかありませんでした。この不一致はローンチ前から把握していましたが、エンジンが処理できないプロンプトにはエラーを返すと想定しており、長文コンテキストのテストでも成功応答が返っていたため、問題視していなかったと説明しています。

2つ目は、プールに収まらない長さのリクエストをSGLangがどう扱うかにあったバグです。収まらないプロンプトは内部的に「拒否」と記録され、1トークンのプレースホルダに置き換えられます。しかしリクエストを中断してクライアントにエラーを返す代わりに、prefillはプレースホルダ分のKVキャッシュを生成してdecodeノードへ転送していました。decodeノードは「転送完了」を受け取り、前のリクエストのKVキャッシュが今回のプロンプトで上書きされたとみなしますが、実際には大半が残ったままでした。

その結果、decodeノードは前のリクエストのデータが残る古いキャッシュページを参照しながら応答を生成しました。クライアントにはHTTP 200が返り、トークン数もプロンプト長と一致し、応答自体も筋の通った文章になっていたため、外から見て異常に気づきにくい状態でした。

修正内容と上流への還元

設定面では、GLM 5.2の構成に合わせる形でGPUメモリを解放し、prefillのKVプールを約204万トークン分に拡張しました。これはコンテキスト長である1,048,576トークンのおよそ2倍で、コンテキスト窓に収まるプロンプトは必ずプールにも収まるようになり、拒否の経路に入りません。Cloudflareはこれだけでこのバグは踏まれなくなるとしています。

エンジン面では、拒否が確定したリクエストを、bootstrap・メモリ確保・KV転送が始まる前の受け入れキューで元のエラーとともに退避させるパッチを適用しました。これは#38704として上流に提案され、decodeノードが転送されたトークン数と予約した数を照合する検証も含まれています。関連する失敗経路の修正#36988は9月6日にSGLangのmainへマージ済みでしたが未リリースで、メンテナーは同様のアプローチでより早い段階に拒否する#38935もマージしています。

一連の修正はSGLang v0.5.20でリリースされ、v0.5.21とv0.5.22で追加対応が入りました。CloudflareはSGLangに依存するすべての運用者に対し、v0.5.22以降への更新を強く推奨しています。同社はWorkers AIでSGLangを使う全モデルにエンジン修正とハードニングを適用し、新規展開時のチェック項目にも加えたとしています。

背景にある仕組みと残る課題

Workers AIのGLM 5.3は、prefill用GPUがプロンプトを処理してKVキャッシュを作り、Mooncake経由のRDMAでdecode用GPUへ渡す分散構成で動いています。GPUメモリ上のKVキャッシュは固定サイズページの共有プールで、リクエストに割り当てられ、終了時に解放されます。性能のためにページはリクエスト間でゼロ埋めされず、次にそのページを割り当てられたリクエストが上書きする仕組みです。

この方式は推論エンジンでは一般的ですが、ページの所有権とライフサイクルの管理はエンジンの責任になります。さらにプールサイズは設定値ではなく、モデル重みを読み込んだ後に残ったGPUメモリから起動時に決まります。モデルの公称コンテキスト長は別の設定値であり、両者が一致することを保証する仕組みはありません。

Cloudflareはテスト手法の穴も認めています。長文コンテキストではHTTPステータスコードと性能だけを検証し、モデル出力の内容や一貫性を確認していませんでした。現在は、分散構成の変更を出す前に、稼働中のエンジンからKVプールサイズとコンテキスト長を直接突き合わせる運用に改めたとしています。