GLM-5.3の応答155件に混ざったのは誰のデータか
2026年10月26日に、CloudflareはAIモデルを動作させるサービス「Workers AI」で提供しているGLM-5.3の応答155件に、他の顧客が送信したリクエスト内容が含まれていたことを明らかにしました。 期間は8月27日〜9月9日で、直前に同じモデルへ送信された別顧客の入力が応答に混ざっていたとのこと。GLM-5.3以外のWorkers AIのモデルに影響は無いとしています。
GLM-5.3はZ.aiが開発したテキスト生成のAIモデルで、エージェント型のコーディングに適しています。自社と研究者のテストを除いた該当リクエストをCloudflareが調べたところ、時期も量も通常の長文利用と変わらなかったといいます。意図的に悪用された証拠は見つかっていないとのこと。
対象は681,280トークンを超える長い入力だけ
GLM-5.3で別顧客のデータが混ざった155件は、どれも681,280トークン（トークンはAIが文章をカウントする単位）より長いプロンプトへの応答でした。 CloudflareはGLM-5.3を1,048,576トークンのコンテキスト（AIが一度に読み込める長さ）で公開していたので、681,280トークンを超えるプロンプトも入力できる状態でした。
GLM-5.3は8月27日にWorkers AIで公開されました。別顧客のデータが応答に混ざる問題は、公開したその日から発生していたとのこと。
"In total, 155 responses were affected, all to prompts longer than 681,280 tokens." ／ "We found no evidence of deliberate exploitation." — 冒頭より公式情報を見る →
混ざっていたのは人名や請求書番号など
問題を報告したKnosticは、検証中に受け取った応答で見つけた情報の種類を公開しています。 混ざっていた情報は次のとおりです。
- 人名、取引先や企業の名前
- 請求書番号とユーロ建ての金額、支払日
- ソースコードの情報、ファイルの保存先
- AIエージェントの作業記録
Cloudflareの報告は、混ざったデータの具体的な中身に触れていません。Knosticによると、問題を再現するのに必要だったのは、Workers AIの有料アカウントとAPIトークン、ネットワーク接続だけとのこと。被害者の認証情報や特別な権限は必要なく、被害者側の操作も不要でした。
Knosticは9月7日、AIモデルの中継サービスOpenRouterを通じてGLM-5.3を使っていたときに最初の異常に気づいたとしています。その後、提供元がCloudflareだと突き止め、自社のWorkers AIのアカウントで検証を進めました。
"Personal names" ／ "Client and company names" ／ "Invoice numbers" — 「The observed leaks」より公式情報を見る →
原因は設定の不一致とSGLangの不具合
Cloudflareは自社で設定が合っていなかったことと、推論エンジンSGLangの不具合が重なったことを原因としています。 推論エンジンはAIモデルを動作させて応答を作るソフトで、SGLangはオープンソースで公開されています。
CloudflareはGLM-5.3の処理を、入力を読み込むprefillと応答を書き出すdecodeに分け、別々のサーバーで動作させていました。prefill側はAIが入力を読んだ途中経過をKVキャッシュという領域に一時的に保存し、そのKVキャッシュをdecode側へ移して利用します。
設定の不一致は、コンテキストの長さとKVキャッシュの容量が合っていなかったことを指します。GLM-5.3は1,048,576トークンのコンテキストで公開されたのに、prefill側のKVキャッシュには681,280トークン分しか保存できませんでした。
Cloudflareは公開前からこの差を把握していましたが、処理できないプロンプトにはエンジンがエラーを出すと考えていました。長文のテストでも正常な応答が届いたため、問題ないと判断したとのこと。ただ、テストで見ていたのはエラーが出たかどうかと性能だけで、出力の中身はチェックしていませんでした。
"We were aware of this mismatch before launch. We expected the engine to return an error for any prompt it could not process, and our long-context tests returned successful responses, so we did not believe this to be an issue." — 「What happened」より公式情報を見る →
SGLangは容量を超えた入力をどう処理したのか
SGLangはKVキャッシュの容量を超えるプロンプトを内部で拒否済みと記録したうえで、1トークンだけの仮入力に置き換えていました。 本来はここで処理を打ち切ってエラーを出すところ、仮入力の分だけKVキャッシュを作ってdecode側へ転送し、処理を続けていたとのこと。
decode側は転送完了の知らせを受け取り、直前のリクエスト内容はすべて上書きされたと見なしました。実際に上書きされたのは仮入力の分だけで、残りの領域には直前のリクエスト内容が残っていました。
decode側はこの古い中身を読んで応答を作ったため、別顧客のデータが応答に混ざりました。KVキャッシュの領域をリクエストのたびに消去せず次のリクエストで上書きして使い回すことは、推論エンジンでは一般的とのこと。
"A prompt that did not fit the pool was internally marked as rejected and replaced with a one-token placeholder, but instead of aborting the request and returning a client error, prefill generated the KV cache for the placeholder prompt and transferred it to the decode node." — 「What happened」より公式情報を見る →
異常な応答にユーザーが気づけないのはなぜか
GLM-5.3のユーザーに届いたのはエラーではなく、正常に処理されたときと同じ応答でした。 本来なら「処理できない」というエラーが届くはずのリクエストです。応答の文面も意味が通っていたため、別ユーザーの入力が混ざっていても、受け取った側は気づきにくくなっていました。
影響を受けたのはGLM-5.3だけです。Workers AIで同じように処理を分けている他のモデルは、KVキャッシュの容量がコンテキストより大きく設定されていたため、この不具合は発生しませんでした。
"GLM 5.3 was the only model affected by this bug. Every other disaggregated deployment on Workers AI has KV pools larger than its context length on both prefill and decode, so no request could reach the rejection path." — 「Issue two: SGLang bug」より公式情報を見る →
Cloudflareは報告の翌日にモデルを止め、同日中に再開
Knosticのセキュリティ研究者Gadi Evron氏は2026年9月8日（協定世界時）に、脆弱性（ソフトやサービスにあるセキュリティ上の欠陥）の報告窓口サービスHackerOneを通じてこの問題を報告しました。 Cloudflareは翌9月9日にセキュリティインシデントを宣言し、製品セキュリティの担当部門が別々の2アカウントを使って、25分以内に問題を再現しています。
Cloudflareは宣言から40分以内にGLM-5.3を非公開に切り替え、同日中に設定を修正して提供を再開しました。研究者やSGLangの開発元RadixArkと日程を合わせ、10月26日にこの問題を公表しました。Cloudflareの報告は、影響を受けた顧客へ個別に連絡したかどうかには触れていません。
報告から公表までの時系列
Cloudflareが報告を受けてから公表するまでの流れは、次のとおりです。 表の時刻は、Cloudflareの報告と同じ協定世界時（UTC）で書いています。
報告から公表までの時系列（Cloudflareの報告より）
| 日時（UTC） | 出来事 |
|---|---|
| 9月8日23時11分 | Gadi Evron氏がHackerOneを通じて報告 |
| 9月9日8時00分 | Cloudflareが報告の検証を開始 |
| 9月9日13時22分 | セキュリティインシデントを宣言し、25分以内に再現 |
| 9月9日14時00分 | GLM-5.3を非公開にし、リクエストにはエラーを出す状態に |
| 9月9日14時52分 | prefillのサーバーをすべて修正後の設定へ切り替え |
| 9月9日19時04分 | 修正した設定とエンジンのパッチで作り直し、研究者の再現手順で検証 |
| 9月9日19時40分 | GLM-5.3の提供を再開 |
| 9月10日 | SGLangを開発するRadixArkと会い、SGLang本体での修正に合意 |
| 10月2日 | SGLang v0.5.21を公開 |
| 10月19日 | SGLang v0.5.22を公開 |
| 10月26日 | Cloudflare・研究者・RadixArkがそろって公表 |
非公開にしてから再開するまでは約5時間40分でした。報告から公表までは約7週間あり、その間にSGLangの修正版v0.5.21とv0.5.22が公開されています。
"Security incident declared. Product Security reproduced the leak using two independent accounts within 25 minutes." — 「Timeline」より公式情報を見る →
KVキャッシュの容量を約204万トークンに拡大
再発防止として、CloudflareはGLM-5.3のprefill側にあるKVキャッシュの容量を、約204万トークンに広げました。つまり、GLM-5.3の設定を前のモデルであるGLM-5.2と同じにしてGPUのメモリに空きを作り、コンテキストの約2倍となる容量を確保しています。
あわせて、拒否したリクエストをdecode側へ転送する前に打ち切るパッチをSGLangに入れ、同じ考え方の修正はSGLang本体にも取り込まれました。SGLangの修正はv0.5.20で公開され、v0.5.21とv0.5.22でも追加の修正があったとのこと。CloudflareはSGLangを使う他の事業者に、v0.5.22以降への更新を勧めています。
今後はKVキャッシュの区画ごとに持ち主の情報を付け、読み出すときに持ち主を確認する仕組みを、SGLangと共同で製品化する計画です。試作では、処理量と遅延への影響は1%未満だったとのこと。
"We adjusted our GLM 5.3 configuration to match our GLM 5.2 configuration, which freed enough GPU memory that the prefill KV pool now holds about 2.04 million tokens, roughly twice the 1,048,576-token context length." — 「Immediate remediation」より公式情報を見る →
外部のAIで発生する事故に備えること
今回の事故はAIサービスを提供する側の設定と不具合によって発生したもので、ユーザーの使い方が原因ではありません。 外部のAIサービスに入力した情報は、提供元の不具合によって別のユーザーへの応答に出ることもあり、入力する側だけでは防げません。したがって会社としては外部のAIに入れてよい情報を先に決め、流出しても困らない範囲に限っておくといいでしょう。
個人情報保護委員会は2023年6月2日に、生成AIサービスを使う事業者と一般のユーザーそれぞれに対する留意点を公表しています。この資料をもとに、会社と社員ができることを紹介します。
会社側：入れてよい情報を決め、提供元の学習利用を調べる
個人情報保護委員会は事業者に対し、個人情報を含むプロンプトを生成AIへ入力するなら、利用目的の達成に必要な範囲内かを十分に確認するよう要請しています。 本人の同意を得ずに個人データを入力し、そのデータが応答の出力以外にも使われると、個人情報保護法に違反する可能性があるとのこと。入力する場合は、提供事業者がそのデータを機械学習に使わないことなどを確認する必要があります。
そのうえで、社内で使ってよいAIサービスと、入力してよい情報・入力してはいけない情報を決め、社員に周知しておきましょう。顧客の個人情報や取引先から預かった資料のように、外へ出ると相手への説明が必要になる情報から先に定めておくといいでしょう。
"当該個人データを機械学習に利用しないこと等を十分に確認すること。" — 「（１）個人情報取扱事業者における注意点」より公式情報を見る →
社員側：利用規約を読み、外へ出て困る情報は入れない
社員側はAIサービスを仕事で使う前に提供事業者の利用規約やプライバシーポリシーを読み、入力する情報の中身を踏まえて使うかどうかを判断します。 個人情報保護委員会も、一般のユーザーに対して同じ内容を呼びかけています。
今回のGLM-5.3のように、提供元の不具合によって入力が別のユーザーへの応答に出ることもあります。会社が使ってよいと定めたサービスでも、外へ出て困る情報はそのまま入れないようにしましょう。パナソニックでも、社内で禁止されていた生成AIに従業員や家族の個人情報がアップロードされています。
"生成 AI サービスを提供する事業者の利用規約やプライバシーポリシー等を十分に確認し、入力する情報の内容等を踏まえ、生成 AI サービスの利用について適切に判断すること。" — 「（３）一般の利用者における留意点」より公式情報を見る →
FAQ
- GLM-5.3以外のWorkers AIのモデルも影響を受けましたか？
- Cloudflareは、GLM-5.3以外のWorkers AIのモデルは影響を受けていないことを確認したとしています。同じように処理を分けている他のモデルは、KVキャッシュの容量がコンテキストより大きく設定されていました。
- 今回の問題は意図的に悪用されたのですか？
- Cloudflareは、意図的に悪用された証拠は見つかっていないとしています。自社と研究者のテストを除くと、該当するリクエストは時期も量も通常の長文利用と変わらなかったとのこと。
- 自社でSGLangを運用している場合は何をすればいいですか？
- prefillとdecodeを分けた構成でSGLangを運用している事業者に対し、Cloudflareはv0.5.22以降へ更新するか修正パッチを取り込むよう勧めています。
関連する記事
パナソニック、利用禁止の生成AIに約33万人分の個人情報をアップロードパナソニック オペレーショナルエクセレンスは10月23日、社内で利用を禁じている外部の生成AIサービスに、従業員や家族など約33万人分の個人情報がアップロードされたと発表しました。生成AIの事業者はAI学習機能が無効だったと回答し、被害は確認されていないとのこと。対象者に求められる対応はありません。
AIワークフロー構築ツール7種に脆弱性14件、プロンプトでコード実行もEndor LabsはDifyやLangflowなど、AIワークフロー構築ツール7種で14件の脆弱性を見つけたと発表しました。なかには認証がなくても、プロンプトからサーバー上でコードを実行できるものもあります。NocoBaseなど4つの製品には修正版が出ていますが、KestraとDifyは修正しない方針で、Flowiseは開発が終了しています。
Cloudflare Clefとは？Jevとの違いと未検証のベンチマークCloudflareが公開した意思決定モデルClefは、Jev互換のAPIで画像や動画も判定でき、料金はJevの約6倍です。軽量版Clef-flashもあり、Workers AIで呼び出せます。7指標でトップというベンチマークの結果はCloudflareの自己申告で、第三者による検証はまだです。
AIサイバー攻撃は1社平均25ドル、AIエージェントで27社に侵入Gambit Securityが2026年9月に公表した、AIサイバー攻撃の事例を解説します。オペレーターは公開中のAIエージェント3種で27社以上を侵害し、2社からカード情報60万件超を持ち出しました。攻撃費用は1社平均25ドル（約3,956円）で、スキマー設置やデータ削除の被害も出ています。