Cloudflare Workers AIのGLM-5.3でKVキャッシュ経由の情報漏えい｜155件の原因と利用者の確認点

Cloudflareは2026年10月26日、Workers AIで提供しているGLM-5.3（@cf/zai-org/glm-5.3）が、2026年8月27日〜9月9日に返した155件の応答に、直前に送られた別の顧客のリクエスト内容が混ざっていたと公表しました。対象は68万1,280トークンを超える長いプロンプトへの応答だけで、9月9日に修正済みです。Cloudflareによると、意図的に悪用された証拠はなく、Workers AIのほかのモデルにも影響はありません。

この記事でわかること

• 何が起きたのか（件数・期間・対象・公表されていないこと）
• なぜ他人のデータが混ざったのか（KVキャッシュとSGLangの不具合）
• Workers AIやOpenRouterの利用者が今確かめること
• SGLangなどの推論サーバーを自社で動かしている企業の確認点
• 外部のAI推論APIを業務で選ぶときに見るポイント

こんな人に向けた記事です

• Workers AIやAI Gateway、OpenRouter経由でGLM-5.3を使っている開発者
• 社内で生成AI APIの利用を管理している情報システム・セキュリティ担当者
• SGLangやvLLMでLLMを自社運用しているエンジニア

Cloudflare Workers AI GLM-5.3の情報漏えいの要点

出典：Cloudflare Blog「Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang」

今回の事故は、長すぎる入力を受けたとき、前の利用者のデータが残ったメモリ領域をそのまま読んで回答を作ってしまったものです。Cloudflareの公式ブログ「Cross-request KV cache exposure in the GLM-5.3 Workers AI model, and our remediation with SGLang」と、報告者であるKnosticの記事をもとに、事実を整理します。

利用者から見て厄介なのは、エラーではなく、HTTP 200の自然な応答として返ってきた点です。アプリ側の監視では異常として検知されにくく、受け取った側は「モデルが少しおかしな回答をした」としか思わなかった可能性があります。

公表されていること・されていないこと

公式発表には、まだ明らかになっていない点があります。

ネット上には「2025年5月」「1.55億リクエスト」など公式と食い違う数字を載せた記事もあります。件数・期間・トークン数は、Cloudflare公式ブログの数字で確認してください。

発見から公表までのタイムライン

報告の受理から約15時間でモデルを非公開にし、同じ日のうちに修正版で再開しています。日時はUTCで、Knosticの欄以外はCloudflare公式ブログの記載です。

GLM-5.3の公開日は、公式ブログでは8月27日、Cloudflareの更新履歴（changelog）では8月28日付になっています。報告者Knosticの記事では、HackerOne上で「解決済み」となったのは9月24日です。これはサービスの復旧日（9月9日）とは別の日付です。

なぜ他人のデータが混ざったのか

原因は「KVキャッシュの容量不足を知りながら公開した設定ミス」と「SGLangの不具合」の2つが重なったことです。仕組みを順に見ていきます。

KVキャッシュとは「前の作業のメモが残る作業台」

LLMは入力文を読むとき、各トークン（単語のかけら）の計算結果をGPUメモリに置いておき、次の文字を生成するときに使い回します。この一時置き場がKVキャッシュです。長い入力ほど多くの場所（ページ）を使います。

たとえるなら、KVキャッシュはページ単位で貸し出される作業台です。使い終わったページは次の人に回されますが、前の人のメモが消されないまま残っていることがあります。通常は新しい内容で上書きされるため問題になりません。今回は上書きされないまま読まれてしまいました。

入力担当と出力担当を分ける構成（prefill/decode分離）

CloudflareはGLM-5.3を、オープンソースの推論サーバーSGLangで動かしていました。その際、処理を2つのGPUノードに分けています。

• prefillノード: 入力文を読み込み、KVキャッシュを作る
• decodeノード: KVキャッシュを受け取り、回答を1トークンずつ生成する

両者の間ではKVキャッシュを高速な通信（RDMA、転送の仕組みはMooncake）で受け渡します。この構成は処理を速くするための一般的な手法で、SGLangのほか、vLLMやNVIDIA Dynamoなどでも使われています。

原因1：KVキャッシュの容量がコンテキスト長より小さかった

prefillノードのKVキャッシュ容量は68万1,280トークンでした。一方、モデルは104万8,576トークンまで受け付ける設定で公開されていました。

KVキャッシュの容量は、起動時にGPUの空きメモリから自動で決まります。コンテキスト長と合わせる仕組みはありません。Cloudflareは公開前にこの差を把握していましたが、長い入力のテストでHTTP応答が成功したため、問題ないと判断しました。公式ブログでは、HTTPのステータスコードと性能だけを確認し、出力の中身が正しいかは確かめていなかったと説明しています。

原因2：拒否すべきリクエストを通してしまったSGLangの不具合

容量を超える長いリクエストは、本来ならprefillノードで拒否されます。拒否されたリクエストは、中身が1トークン分の仮のデータに置き換わります。

ところが、decodeノードの受付処理は「拒否されたか」ではなく「処理が終わったか」で判定していました。そのため、拒否されたリクエストが通常どおり先に進んでしまいました。

1. decodeノードは、元のプロンプトの長さに合わせてKVキャッシュのページを確保する（例：8ページ）
2. prefillノードは仮のデータ1ページ分だけを送り、「完了」と通知する
3. decodeノードは確保した8ページすべてを読んで回答を生成する
4. 2ページ目以降には、直前の別リクエストのデータが残っていた

こうして、他の顧客のプロンプトの内容をもとにした回答が返されました。同じ不具合は、2026年7月に別の利用者がSGLangのissue #30233として報告していましたが、動きがないまま9月5日に自動で閉じられていました。

「サイドチャネル攻撃」とは別の種類の漏えい

複数の利用者でKVキャッシュを共有する仕組みについては、応答時間の差から他人の入力を推測する「サイドチャネル攻撃」の研究があります。今回はそうした推測ではありません。古いページの中身をそのまま読んで回答に使ってしまった、直接的な混入です。攻撃に必要だったのも、特別な技術ではなく、通常の有料アカウントとAPIトークンだけでした。

影響を受けた可能性がある人・ない人

影響の可能性があるのは、期間中にCloudflare上のGLM-5.3へ68万トークンを超える長文を送った利用者と、期間中にGLM-5.3を使っていた利用者です。前者は他人のデータを受け取った側、後者は自分のデータが漏れた側になりえます。

注意したいのは中継サービス経由の利用です。報告者のKnosticは、もともとOpenRouter経由でGLM-5.3を使っていたときに不審な出力に気づき、そこから提供元をCloudflareと突き止めました。自社ではCloudflareと契約していなくても、使っているサービスの裏側でWorkers AIが動いていれば影響しえます。

GLM-5.3そのものの性能や特徴はGLM-5.3とは？Z.ai最新モデルの性能・料金で、影響のなかった兄弟モデルはGLM-5.3 Flashの解説とGLM-5.2とはで紹介しています。

Workers AI・OpenRouter利用者が今確かめること

出典：Cloudflare Docs「Workers AI」

Cloudflareは利用者向けの個別の対応手順を出していません。次の表は、公表内容をもとに当社が推奨する確認手順です。

まず、自分が受け取った側か（長文を送った）と、自分のデータが漏れた側か（期間中に使った）を分けて考えてください。漏れた側かどうかは利用者だけでは確かめられないため、機密を含めていたかどうかで対応の重さを決めるのが現実的です。

Cloudflareのデータ利用ポリシーでは、通常の推論の入出力は処理後に保持しないとされています。ただし、AI Gatewayのログやキャッシュを有効にしている場合は、自社側のログに入出力が残っています。確認に使える一方で、そのログ自体の管理も見直しておくと安心です。

「幻覚」か「他人の情報」かを見分ける方法

LLMが見覚えのない内容を返したとき、多くの人はまず幻覚（もっともらしい作り話）を疑います。Knosticは、条件を変えて比べることで、幻覚と他人のデータの混入を見分けました。

Knosticの記事「Hallucination or Cross-Tenant?」で紹介されている方法は次のとおりです。

• 目印を入れる: プロンプトの先頭と末尾に固有の文字列を置き、大量の埋め草で長さを調整する。正しく読めていれば目印を答えられる
• 出力のぶれを抑える: temperatureを0にして、同じ条件で何度も試す
• 長さを変えて境界を探す: 約66.2万トークン未満では目印を正しく返し、約70万〜81.2万トークンで異常が出た（約74.5万で安定して再現）。境界で応答時間も急に変わった
• 比較対象を用意する: 空のプロンプトや、GLM-5.3 Flash・GLM-5.2など兄弟モデルで同じ試験を行い、そのモデル特有の現象かを確かめる

Knosticが受け取った応答には、人名、取引先名、請求書番号、ユーロ建ての金額、支払日、ソースコードの情報、作業フォルダのパス、AIエージェントの作業記録などが含まれていました。macOSから送ったのにLinuxのパスが返ってきた例や、プロンプトにない識別子を含むシェルコマンド（公開リポジトリの内容と一致）もあったとのことです。自分の環境ではありえない情報が具体的に出てくるかどうかが、見分ける手がかりになります。

これらは報告者が観測した例です。Cloudflareは漏れたデータの種類を特定していません。

Cloudflareの再発防止策

Cloudflareは、設定の修正とSGLang本体の修正の両方を行っています。

公式ブログは教訓として、HTTPコードと性能だけでなく、出力の中身まで検証すべきだったこと、設定のチェックだけでは足りず、データを読み出す時点で誤りを検知する仕組みが必要なこと、自社だけのパッチではなくオープンソースのSGLang本体に対策を入れることを挙げています。

SGLangを自社で動かしている企業の確認点

出典：GitHub「sgl-project/sglang」

SGLangでprefill/decode分離の構成を使っている企業は、v0.5.22以上への更新とKVキャッシュ容量の確認を優先してください。Cloudflareは公式ブログで、運用者向けに次の5項目を推奨しています。

SGLangの版ごとの主な修正は次のとおりです。

性能への影響は小さいとされています。海外メディアUnite.AIの報道では、SGLang側の計測でH100では±2%以内と紹介されています。

vLLMやNVIDIA Dynamoなど、ほかの推論サーバーに同じ不具合があるとは発表されていません。ただし、「KVキャッシュ容量とコンテキスト長が合っているか」と「長い入力で出力の中身まで正しいか」の2点は、prefill/decode分離の構成ならどの製品でも確かめておく価値があります。

また、公開の脆弱性データベースには、SGLang 0.5.19以前でMooncakeの検証不備からメモリ枯渇を起こす脆弱性（CVE-2026-93688）も登録されています。今回の情報漏えいとは別の問題ですが、v0.5.22以上に更新すれば両方への備えになります。

Workers AIのデータ利用ポリシーとの関係

出典：Cloudflare「Trust Hub」

Workers AIのデータ利用ポリシーでは、次のように定めています。

• 顧客のコンテンツをAIモデルの学習に使わない
• 通常の推論では、処理が終われば入出力を保持しない
• 他の顧客にコンテンツを提供しない

今回の事故は、ポリシーの書き方の問題ではありません。推論サーバーの不具合で、他の顧客に内容を見せないという約束が技術的に守られなかったケースと言えます。「学習に使わない」「保存しない」という約束は大事ですが、それだけでは処理中のデータが他の利用者と混ざらないことまでは保証できません。

Knosticも、「推論システムは状態を持つので、データベースやストレージと同じようにテナント（顧客）ごとの分離が必要」と指摘しています。生成AIの情報漏えいのリスク全体は生成AIのセキュリティリスクと情報漏洩対策で、エージェントに長い作業記録を渡す場合の注意点はAIエージェントのセキュリティ対策で整理しています。

業務で外部のAI推論APIを選ぶときの確認点

業務で外部のAI推論APIを使う場合は、料金や性能だけでなく、データの扱いと事故が起きたときの対応も比べてください。今回の件を踏まえた確認点は次のとおりです。

社内で生成AIを使う場合は、扱うデータの機密度に応じて、共有型のAPIで足りるのか、専用環境やVPC内での運用が必要なのかを先に決めておくと、今回のような事故の影響を抑えやすくなります。構成ごとの違いは生成AIのセキュリティ要件と社内導入の構成で比較しています。

GLM-5.3をこれからも使ってよいか

修正後のGLM-5.3は、9月9日から通常どおり提供されています。料金は100万トークンあたり入力1.40ドル、キャッシュ入力0.26ドル、出力4.40ドルで、Workers Paidプラン（またはAI Gatewayの前払いクレジット）が必要です。インシデントによる料金やプランの変更は確認できていません。

引き続き使ってもよい人

• 公開情報や社外秘でないデータを中心に使う開発者
• 修正内容と再発防止策を確認し、自社の基準で許容できると判断した人
• AI Gatewayなどでログを管理し、異常な応答に気づける体制がある人

慎重に判断したほうがよい人

• 顧客の個人情報や未公開のソースコードを、数十万トークン規模でまとめて送る使い方をしている人
• 医療・金融など、共有型の推論環境の利用に社内規程や業界規制で制約がある企業
• 中継サービス経由で使っており、実際の提供元を把握できていない人

Cloudflareのほかの動きは、Cloudflare OSとはでも紹介しています。AI関連サービスで起きたほかの流出の例としては、Claude Codeソースコード流出まとめも参考になります。

よくある質問

Q. 自分のデータが漏れたかどうかを確かめる方法はありますか？

現時点では、利用者が自分で確かめられる公開の手段はありません。Cloudflareは影響を受けた顧客の一覧や照会窓口を示していません。期間中にGLM-5.3へ機密情報を送っていた場合は、漏れた前提で鍵のローテーションや社内報告を検討し、詳細はCloudflareのサポートに問い合わせてください。

Q. 短いプロンプトしか送っていなければ安全ですか？

受け取った応答については、公式発表によれば心配いりません。混入が起きたのは、68万1,280トークンを超える長文への応答だけとされています。ただし、自分の短いプロンプトの内容が、直後に長文を送った別の利用者の応答に混ざった可能性は、理屈の上では否定できません。

Q. GLM-5.3というモデル自体に問題があったのですか？

Cloudflareの説明では、モデルの問題ではありません。原因はCloudflareの推論環境の設定と、推論サーバーSGLangの不具合です。Z.aiなど別の提供元が別の構成で動かしているGLM-5.3は、今回の不具合とは直接関係しません。

Q. CVE番号は付いていますか？

現時点では、今回の件にCVE番号が付いたことは確認できていません。SGLangのCVE-2026-93688は、メモリ枯渇を起こす別の脆弱性です。

Q. 10月26日まで公表されなかったのはなぜですか？

Cloudflareは、SGLang側・報告者と時期を合わせて公表する「協調開示」をとりました。協調開示は一般に、同じソフトを使う他社が修正版を入れる前に悪用されるのを防ぐための方法です。今回も、SGLangの修正版（v0.5.21・v0.5.22）が出た後に公表されています。

まとめ

• Cloudflare Workers AIのGLM-5.3で、2026年8月27日〜9月9日に、68万1,280トークン超の長文への応答155件に別の顧客のリクエスト内容が混ざっていた
• 原因は、KVキャッシュの容量がコンテキスト長より小さかった設定ミスと、拒否すべきリクエストを通してしまったSGLangの不具合の重なり
• 9月9日に修正済み。悪用の証拠はなく、ほかのモデルへの影響もない。影響顧客数や通知の有無は非公表
• 利用者は、期間中の利用・長文の送信・機密情報の有無をログで確かめ、必要なら鍵のローテーションと社内報告を行う
• SGLangを自社で動かす企業は、v0.5.22以上への更新とKVキャッシュ容量の確認を優先する
• 外部のAI推論APIを選ぶときは、学習・保持のポリシーだけでなく、事故の公表姿勢や専用環境の有無も比べる