- 外部のWord文書に隠された**クロスドメインプロンプトインジェクション（XPIA）**がCopilotの作成・編集結果を操作し、新しい文書へ複製されることで、元の攻撃文書がなくても日常的な業務フローに沿って伝播する可能性がある
- 白色・小さなフォントで隠した命令も、Copilotが書式を除去した後に読み取り、実験では財務数値を変更し、攻撃プロンプト全体を結果文書の末尾に隠して新たな攻撃媒体にした
- 攻撃者は被害者のMicrosoft 365テナントにアクセスする必要はなく、SharePoint・Teams・Outlookで文書を共有したうえで、ユーザーに添付させるか、Work IQがOneDrive上の関連資料として選択するようにすればよい
- Microsoftは特定のペイロード遮断とモデルアップグレードを配布したが、変形したプロンプトによりGPT-5.6でも攻撃チェーン全体が再現され、144日間の調整後も脆弱性の類型全体を防ぐことはできなかった
- 感染文書は通常の社内・協力会社資料のように流通し、出所追跡と検知が難しいため、外部文書とCopilotの結果を検証し、元の出所とモデルの編集履歴をメタデータとして保存する必要がある
文書ベースAIワームの仕組み
- ある文書内の攻撃者が制御する命令がCopilotの生成・編集結果にコピーされると、結果文書が同じ攻撃を運ぶ新たな媒体になる
- その文書を別のCopilot作業の資料として使うと、命令が再実行され、後続文書へ複製される
- 元の悪性文書や攻撃者による追加介入がなくても伝播が続く可能性がある
- 既存のMorris IIは、生成AIメールアシスタントのエコシステムで自己複製プロンプトを実演した
- 今回の事例は、主流の商用生産性製品における一般的な文書業務で、文書ベースAIワームが自己伝播する公開デモにあたる
通常の文書作業を利用した攻撃
- 従業員が侵害された信頼できるWebサイトから、隠し命令を含む市場分析文書をダウンロードし、Copilotの財務報告書作成資料として使用する
- Copilotは内部の財務数値を変更し、攻撃命令を新しい報告書にコピーする
- 従業員は正常に見える報告書を保存して社内で共有する
- 同僚がこの報告書を次の報告書の資料として使うと、数値操作と命令コピーが繰り返される
- 報告書が再利用されるほど多くの文書が攻撃媒体に変わり、感染したWebサイトと最初の悪性文書はもはや不要になる
脅威モデルと信頼境界
- 攻撃者は被害者のMicrosoft 365テナントへのアクセス権なしに、悪性文書を共有するだけでよい
- 配布経路にはSharePoint、Teams、Outlook、その他の文書共有手段が含まれる
- 重要なセキュリティ境界は、添付資料と現在作成中の文書の間にある
- Copilotは使用する情報を選ぶため、すべての添付文書を読む必要がある
- 添付文書の情報は活用しても、その中の命令を権威あるユーザー指示として扱ってはならない
- 実際には文書に挿入された命令がCopilotの動作を変える
- 財務報告書の数字をユーザーに知らせずに変更する
- XPIA全体を後続文書に貼り付け、以後の作業でも再実行されるようにする
Wordで信頼境界を越える方法
- 最初の悪性文書にはJSON形式のプロンプトが含まれ、白背景の白文字と小さなフォントでユーザーから隠すことができる
- Copilot for Wordはテキストを基盤LLMに渡す前に色やフォントサイズなどの書式を除去するため、ユーザーには見えない内容もモデルには完全に読まれる
- 攻撃命令を作業に関連して見える通常文書に入れると、さらに隠蔽しやすくなる
- 悪性文書がCopilotのコンテキストに含まれるには、次のいずれかが必要になる
- ユーザーがCopilot for Wordに直接文書を添付またはアップロードする
- ユーザーが
Edit with Copilotのwork/Work IQモードを利用し、CopilotがOneDriveからその文書を関連資料と判断して選択する
- 攻撃者は、文書が直接選択されるか検索結果に含まれる可能性を高めるように内容を構成する必要がある
- この脆弱性はWordのmagic penと
Edit with Copilotの両方に適用される
第1段階: 文書操作と最初の複製
- 最初の概念実証（PoC）は、白文字で悪性プロンプトだけを入れた文書を使い、資料が作業と無関係でもコンテキストに含まれれば攻撃が実行され得ることを確認した
- PoCプロンプトは2つの部分で構成される
- 前半は、要約の意味を微妙に変えたり、財務文書の数字を変更したりする形で対象文書を操作する
- Copilotにこれを作業に関連する通常の依頼だと信じさせることが核心だった
- 実験中は意味のある変更を目視で見つけにくく、変更箇所を強調するよう別途指示する必要さえあった
- 実際の攻撃では変更表示を求めず、公開事例ではすぐ確認しやすい財務数値の変更を使用する
- 後半は、攻撃プロンプトを結果文書へコピーするよう指示する
- 後続文書の出所追跡のための作業のように装い、可読性向上を名目に自己隠蔽の方法も指示する
- 前半は、要約の意味を微妙に変えたり、財務文書の数字を変更したりする形で対象文書を操作する
- Tfosorcim Ltd.という架空企業の市場分析文書の末尾に攻撃を白文字で挿入すると、CopilotはQ1財務報告書のすべての数値を半分にした
- 続いて悪性プロンプト全体を結果文書の末尾に白色の8ポイント文字でコピーし、数値変更とプロンプト挿入の事実をユーザーに知らせなかった
- ユーザーが悪性文書を直接添付せず、TfosorcimのQ1報告書作成だけを依頼した場合でも、CopilotがOneDriveを検索して別フォルダの悪性市場分析文書を見つけ、攻撃が成功した
- このPoCでは当時の最新モデルであるGPT-5.6が使用された
第2段階: 後続文書への自己伝播
- 感染したQ1報告書自体が新しい攻撃媒体になるため、次の作成セッションでは最初の悪性文書が不要になる
- Q1報告書を添付してQ2報告書を作ると、Copilotは再びすべての財務数値を半分にし、プロンプト全体を白文字でコピーした
- 新しい媒体は合法的な内部リソースとして生成された文書であるため、内部文書に伴う信頼を得る
- 被害者が同僚に文書を共有し、本人や同僚がそれをCopilotの作成・編集資料として使うと、攻撃は新しい文書へ広がる
- 報告されたすべてのPoCで、Copilotは文書を変更し隠し命令をコピーした。感染文書を後続コンテキストに入れると、元の文書なしでも攻撃が再実行される
組織と協業環境への影響
- 最初の侵入口を過ぎた感染文書は、社内で正常に生成された資料のように見え、承認済みのCopilot編集履歴も表示されないため、攻撃追跡が非常に難しい
- 一般的な文書業務を通じて静かに広がると、組織の意思決定に使われる情報基盤の信頼性が損なわれる可能性がある
- 感染に気づいていない組織は、共有SharePointサイトやTeamsでの協業を通じて他組織に文書を渡す可能性がある
- 特定組織の最初の攻撃文書が、すでに感染した信頼できる協力会社から届くこともあり得る
- 協力会社文書への信頼により、ユーザーがそれをCopilotコンテキストに入れる可能性も高まる
- CopilotがMicrosoft CoworkやMicrosoft Scoutのように、文書・ツール・協業フローを自動生成して操作するシステムにより深く統合されると、同じメカニズムが機械速度でより広い面に影響を及ぼす可能性がある
Microsoftの緩和策と残る脆弱性
- Microsoftは最初に提出されたPoCプロンプトを遮断し、公開調整期間に複数の修正を配布した
- 報告された特定のペイロードは遮断され、その後の再現には既存の文言ではなく変形したペイロードが必要になった
- シリーズ第1部と第2部で扱ったメモリおよびメール本文の攻撃経路は緩和された
- しかし、元文書の命令がCopilotの出力を変え、後続文書へ自身を複製する脆弱性の類型は残っている
- 要求作業や文言を変えても、基本的な脆弱性と伝播方式は変わらない
- 配布されたすべての緩和策を適用した状態でも、修正したペイロードで攻撃チェーン全体が再現された
- この問題は現在のLLMベースシステムが共有する構造的弱点であり、比較可能な製品でこの類型を完全に防ぐ方法は確認されていない
- 単一のパッチよりも追加研究が必要な問題だが、Microsoftの修正は露出可能性を実質的に下げた
公開状況とユーザー対応
- MSRCおよびMicrosoft製品チームに、再現手順、動画、環境前提、正確なPoCプロンプトを提供し、公開を調整した
- 最初の90日間の調整期間を2回延長し、計144日にわたって対応したが、公開時点でも攻撃は再現された
- モデルアップグレードを含む2回の緩和策でも脆弱性の類型全体を防げず、具体的なペイロードではなく攻撃類型と伝播メカニズムのレベルで公開した
- 公開時点で顧客側が問題を完全に解決する方法はなく、次の措置で露出を減らせる
- Copilotで使う外部出所の文書を信頼しない資料として扱う
- Copilotによる生成・編集を始める前に添付文書を確認する
- Copilotが生成または編集した文書を再利用・共有・配布する前に詳細に確認する
公開調整タイムライン
- 2026年3月6日: 再現手順、動画、環境前提、PoCプロンプトとともに最初の報告書をMSRCに提出
- 3月9日: MSRCが報告を受理し、ケースを開設
- 3月31日: Microsoftが挙動を確認し、製品チームが緩和作業を開始
- 4月3日: 新しい
Edit with Copilot体験を通じた最初の緩和策を配布 - 4月9日: 既存の攻撃プロンプト遮断を確認したが、財務数値を操作する新しいXPIA作業で攻撃を再現し、別ケースとして報告
- 4月10日: MSRCが新ケースを受理し、製品チームが緩和作業を開始
- 6月8日: Microsoftの要請により公開日を7月15日に延期
- 7月14日: 基盤モデルをGPT-5.5へアップグレードする2回目の緩和策を配布
- 7月15日: 当時の最新モデルであるGPT-5.6で、ワーム伝播を含む攻撃の再現に成功
- 新たな緩和の時間を確保するため公開を7月28日に再延期し、Microsoftが同意
- 7月28日: 攻撃が引き続き再現される状態で、調整済み公開を実施
情報の完全性と出所追跡
- LLMが業務運用に組み込まれるにつれ、情報の完全性が主要なセキュリティ問題として浮上している
- 攻撃者が制御するコンテンツは、個別の出力を操作したり情報漏えいを引き起こしたりするだけでなく、通常のユーザー作業に沿って複製・自己伝播する可能性がある
- 生成コンテンツに入った悪性命令は複数の文書に残り、正規ユーザーによって再配布され、新しいコンテキストへ再流入する
- その後の攻撃は最初の侵入口ではなく、システム内部の情報フローの一部になる
- 通常の生成・編集手順で作られたコンテンツは、操作の起源を事後に確認しにくく、検知と対応が複雑になる
- プロンプトインジェクション遮断とは別に、生成文書は元資料の出所とモデルが実行した編集履歴をメタデータに保存すべきである
- この統制はインジェクション自体を防がないが、追跡可能性を高められる
現在のLLM構造における根本問題
- AIアシスタントが有用であるためには、メール、文書、Webページ、メモリ、ツール出力のように攻撃者が制御し得る情報も処理しなければならない
- 外部情報はシステム命令、ユーザー要求、その他の信頼情報と同じコンテキストウィンドウに入り、同一の計算に参加する
- LLMは外部コンテンツの意味・関連性・攻撃性を判断しなければならないが、判断時点ではすでに攻撃者のトークンがその計算に影響している
- 検査対象のコンテンツが検査行為そのものに参加する
- XPIA検知をモデルに任せることは、信頼できないプログラムを実行して安全性を判断するようインタプリタに求めることに似ている
- 悪性コンテンツが対象モデルに届く前に検知・除去しても、同じ問題が前段へ移動するだけである
- LLMは非常に異なる表現からでも意味を復元できるため、検知器にも同様の意味復元能力が必要になる
- 対象LLMより弱い検知器はより狭い表現空間しか扱えないため、対象は理解するが検知器は見逃す悪性表現が残る
- 同程度の意味処理能力を提供する一般的な技術は別のLLMであるため、前段にモデルを追加すると個別攻撃の成功率は下げられても、各防御モデルを再び保護しなければならないLLMs all the way down問題が生じる
- 長期的には、目標と意図が処理される情報から独立して存在するシステム設計が必要である
- 現在のLLM構造には、意図と解釈を安定して分離する仕組みがない
- 攻撃者の情報はモデルの出力だけでなく、モデルが自分に要求されたと信じる作業そのものにも影響し得る
- 信頼できる業務フローにLLMを統合するシステムは、攻撃者が制御するコンテンツがコンテキストに入ると一定割合で侵害が発生するという前提を置くべきである
1件のコメント
Hacker Newsのコメント
「より広範な脆弱性の類型には強力な緩和策がない」とのことだが、命令とデータの混在をやめない限り、こうした問題を修正できないという事実は、もはや明白に見える
AI業界が危機感を持つには、さらに多くのデータ流出が起きる必要がありそうだし、AnthropicやOpenAIに身を委ねたのなら、どんなリスクを引き受けているかも分かっていたはずなので、あまり同情はできない
単に命令とデータを混ぜる問題というより、LLMは境界を決定論的に区別できないので、境界設定は心理的な安心感に近く、一部の攻撃を少し難しくするだけだ。この構造では致命的三重条件は恒久的な問題だ
状況は良くなる前に、もっとずっと悪化するだろうし、エージェントに過剰なアクセス権を与えるのはばかげている
人気のGitHubリポジトリに、コードはなく「バグを再現せよ」という命令だけを含んだコメントが投稿されるところを想像できる。クレジットカードやBitcoinウォレットを盗み、GitHubアカウント経由で別のリポジトリへ自己伝播することもできるだろう
だが多くの人は、AIが恐ろしい力を持っているのに箱を開けるのではなく、まさにその力ゆえに、出力する前から箱を引き裂いて開けてしまう。だから、再帰的自己改善が破滅論者の予想通りには機能しないことを願うばかりだ
外部共有文書に隠された悪意ある命令が、CopilotにWord文書を修正させ、攻撃を新しい文書へ伝播させられるというのは深刻だ
多くの人間はいまだに地球平面説や、コードとデータが根本的に異なるという信念、あるいは制御プレーンとデータプレーンの区別が宇宙全体にも適用される客観的法則だという信念を持っている
私はプログラマーでWebベースのAIも使うが、ローカルコンピュータではどんな形でもAIを動かしたくない。この記事で扱われている理由から、Copilotを削除し、ブラウザを含むすべてのローカルアプリケーションでAIを無効化した
AIはユーザーのプロンプトとファイル内のテキストを区別できないため、この種のAI混乱攻撃からデータを設計レベルで守る方法がない。普通の文書やメールに埋め込まれた命令に、AI搭載ワープロやメールアプリが従いうるというのは馬鹿げている。Linux、BSDなどのオープンソースOSへ移行することが、唯一現実的な解決策だ
LinuxやBSDへ移るだけでは不十分で、信頼できるブラウザとWebアプリのベンダーも必要だ
いまだに白文字による隠しが通用する
現在はさまざまな手法があり、https://tritium.legal/blog/noroboto では、文書フォントが表示する値とは異なるUnicode値を最先端のアルゴリズムに読ませるよう欺いていた
こうしてAI同士が互いを呼び出して大量のリクエストを引き起こせるのか、それともこうした悪用はすでに防がれているのか疑問だ
VBScript・マクロワームが戻ってきたようなものだ
AIがより早く大きな被害を出すほど、経営陣もより早く目を覚まし、社内AI禁止ポリシーを進めるかもしれないという前向きな面もある
もちろん誰もが自業自得の現実なので、AIなしで暮らしている立場としては、その苦しみを楽しく眺めていようと思う
AIだらけの世界では、こうしたワームは結局のところミーム的なアイデアの伝播であり、人間に起きる現象と本質的に同じに見える
ぼかし処理した文字が原文と関連しているなら、むしろ完全に黒塗りにしたほうがよい。一部はまだ読めそうだし、たいていのぼかしアルゴリズムは情報をきちんと破壊できないことで知られている