Cloudflareは2026年10月26日（UTC）、Workers AIのGLM-5.3（@cf/zai-org/glm-5.3）で、他のユーザーのテキストが応答に混ざる「KVキャッシュ露出」があったと公式ブログで明らかにしました。すでに修正済みです。Workers AIでGLM-5.3を使っている人や、自前でSGLangを動かしている人に関係する話です。
KVキャッシュ露出の結論：影響はGLM-5.3だけ、修正は済み
結論から言うと、影響を受けたのはGLM-5.3だけです。期間は2026年8月27日から9月9日で、Workers AIの他のモデルには影響がなかったとされています。影響を受けた応答は合計155件でした。いずれも681,280トークンを超える長いプロンプトへの応答です。
| 項目 | 公式ブログの内容 |
|---|---|
| 対象 | Workers AIのGLM-5.3のみ |
| 影響期間 | 2026年8月27日〜9月9日 |
| 影響を受けた応答 | 155件（681,280トークン超のプロンプトへの応答） |
| 悪用の証拠 | 研究者とCloudflare自身のテストを除くと、意図的な悪用の証拠は見つからなかった |
| 状態 | 9月9日に設定を修正し、同日中に一般公開を再開 |
何が起きたのか：長いプロンプトで他人のKVキャッシュが返った
AIモデルは、過去の入力を計算した結果を「KVキャッシュ」という領域に置いて使い回します。つまり、毎回ゼロから計算し直さないための置き場です。ところが今回は、その領域に書き込まれていない古いデータを読み出してしまいました。それが別のユーザーの応答になったのです。
きっかけは、2026年9月8日にKnostic社の研究者がHackerOne経由で報告した内容です。非常に長いプロンプトを送ると、他のユーザーのセッション由来のテキストが返ることがある、というものでした。Cloudflareは翌9日に再現しました。そのため、モデルを一時的に非公開にして修正しています。
KVキャッシュ露出の原因：設定の不整合とSGLangのバグ
原因は、2つが重なったことです。つまり、設定とエンジンの両方に問題がありました。
- 設定の不整合: モデルのコンテキスト長は1,048,576トークンなのに、prefill側のKVキャッシュのプールは681,280トークン分しかありませんでした
- SGLangのバグ: プールに収まらない要求が、本来のエラー中止ではなく1トークンのプレースホルダーに差し替えられて処理が続きました。prefillとdecodeを分けた構成では、拒否済みの要求が中止されず、decode側が書き込まれていないKVページを読んでしまいました
その結果、本来ならHTTP 400で断られるはずの要求が通りました。HTTP 200で、他のユーザーのデータを含む応答が返ったのです。食堂にたとえると、「この席は満席です」と断るはずが、前の客の食べ残しの皿をそのまま出してしまった、という感じです。
このバグは2026年7月に、別のユーザーからSGLangへissue（#30233）として報告されていた、と公式ブログに書かれています。
Cloudflareの対応と時系列
2026年9月9日（UTC）の流れは次のとおりです。
| 時刻 | 出来事 |
|---|---|
| 13:22 | インシデントを宣言 |
| 14:00 | モデルを非公開にした |
| 14:35 | 根本原因を特定 |
| 14:52 | すべてのprefillノードを修正済みの設定へ切り替え |
| 19:40 | 一般公開を復旧 |
そのうえで、恒久的な対処は2つです。
- 設定をGLM-5.2と揃え、prefillのKVプールを約204万トークン（コンテキスト長の約2倍）に拡大しました
- エンジン側で、拒否された要求を転送や割り当ての前に終了させる修正を入れました。上流のSGLangには#38704を提案し、#36988と#38935がマージされています
検証には、研究者の再現スクリプトとカナリア型のテストを使ったとのことです。なお、今回の公表はSGLangチームの投稿と合わせた協調開示として行われました。
KVキャッシュ露出を受けて、やっておきたいこと
Workers AIでGLM-5.3を使っている人
- 2026年8月27日から9月9日の間に、GLM-5.3へ非常に長いプロンプトを送っていなかったかを、自分のログやアプリの記録で見返しておくと安心です
- 影響を受けた顧客への個別の連絡方法や、顧客側で必要な対応（認証情報の変更など）は、公式ブログに記載がありません。ですから、心配な場合は、Cloudflareのサポートに問い合わせるのが確実です
- 日本での提供状況や、日本の利用者への影響についても、公式ブログに記載はありません
自前でSGLangを運用している人
一方、公式ブログが他の運用者に勧めている点は、次の5つです。
- KVプールのサイズとコンテキスト長を比較する。重みや量子化、並列化、メモリ割り当てを変えるたびに、すべてのprefillノードとdecodeノードの起動ログで確認し、プールが小さければコンテキスト長を下げる。プロキシによる制限やエンジンによる拒否を前提にしない
- 修正（#36988と#38935）を含むビルド（v0.5.22以降）にアップグレードする。プールサイズに関係なく、長すぎる要求がハンドオフの前に拒否される。（v0.5.21は10月2日、v0.5.22は10月19日にリリース）
- prefillとdecodeの両方でdeferred KV releaseを有効にし、Mooncakeの転送バッチ数に上限を設ける。deferred releaseは#41023以降、デフォルトで有効
- 対応モデルでは破損検出を有効にする。
--disaggregation-enable-kv-checksumと--kv-canaryを使い、ログで要求が検証されているか確認する。両機能はまだすべてのモデルアーキテクチャには対応していない - プロキシが不要なabortを出さないようにする。ロードバランサーは、最初のトークンが出るまで要求を進めるよう設定し、ノード間の調整が必要なabortを発生させない
今回の件から見えること
公式ブログによると、今回はコンテキスト長とKVプールの大きさの照合が強制されていませんでした。だから公式は、プロキシの制限やエンジンの拒否に頼らないよう求めています。自分の環境で、起動ログから確認するということです。長い入力を扱うAIサービスは、容量の上限と、上限を超えたときの動きまで確認しておくと、迷いません。
ほかのITの話題は、技術ネタの記事一覧からどうぞ。
2026年10月26日（UTC）の公式ブログの情報をもとにしています。
ITもごはんも、腹八分目が長続きのコツ！
コメント