Microsoft 365 Copilot Enterprise の脆弱性チェーン「SearchLeak」(CVE-2026-42824)を解説。細工した正規URLを1回踏むだけでメール・OneDrive・SharePointの情報が抜かれる仕組みと、なぜEPやURLフィルタで防げないのか、そして自社AIアプリを作る側が持ち帰るべき設計の教訓をまとめる。
2026年6月、Varonis のリサーチャーが「SearchLeak」と名付けた攻撃手法を公開した。Microsoft 365 Copilot Enterprise に細工したリンクを1回踏ませるだけで、被害者のメール、OneDrive、SharePoint から機密情報を盗み出せる、というものだ。盗める情報には、メール本文に含まれるアクセスコードやパスワード、会議の予定、社内ドキュメントなどが含まれる。
Microsoft はこの問題に CVE-2026-42824 を割り当て、6月初旬にバックエンド側で修正済み。Varonis が示したのは概念実証、つまり PoC であり、実際の攻撃が観測されたわけではない。利用者側でパッチを当てる、設定を変える、といった対応が必要な話ではない。
それでもこの事件を取り上げる理由は、自社でAIアプリやエージェントを作る企業にとって、「絶対にやってはいけない設計」の見本そのものだからだ。
SearchLeak は、それぞれ単体では大きな攻撃に見えない3つの弱点を、鎖のようにつないで成立する。
SearchLeak の入口は、Copilot Enterprise Search の検索URLだ。
検索サービスでは、検索語をURLのクエリパラメータに入れて開けることがある。たとえば検索画面で何かを探すと、その検索内容がURLにも反映される。これは検索サービスとしては自然な設計だ。
SearchLeak では、この検索語の部分に、単なるキーワードではなく Copilotへの命令文を埋め込む。
攻撃者は、Microsoft 365 / Copilot Search への正規リンクを用意する。被害者がそのリンクを開くと、Copilot はURLに含まれた文字列を「ユーザーからの検索指示」として処理し、メール、OneDrive、SharePoint などを検索し始める。
被害者は Copilot に何も入力していない。ただ、正規の Microsoft リンクを開いただけだ。
しかし、そのURLの中には、最初のプロンプトがすでに仕込まれている。
ここが SearchLeak の入口だ。
次に使われるのが、Copilot の回答表示まわりの挙動だ。
Copilot は回答をストリーミング表示する。その途中で、危険なHTMLが無害化される前の一瞬だけ、生のHTMLがブラウザに描画されてしまう。
本来であれば、<img> のようなHTMLはコードブロックとして扱われ、実行されない形にされるべきだ。ところが SearchLeak では、その無害化処理が完了する前のわずかなタイミングで、攻撃者が Copilot に吐かせた <img> タグが実際に発火する。
つまり、Copilot の回答文の中に埋め込まれたHTMLが、ただの表示テキストではなく、外部通信を起こす部品になってしまう。
最後のひと押しが SSRF だ。
SSRF は Server-Side Request Forgery の略で、日本語では「サーバサイドリクエストフォージェリ」と呼ばれる。
簡単に言えば、攻撃者の代わりに、信頼されたサーバへ通信させる攻撃だ。
普通、リンクを踏んだときに通信するのは、利用者の端末だ。ところが SSRF では、信頼されているサーバ側をだまして通信させる。
会社で例えるとこうなる。
外部の人間は、正面ゲートから勝手に荷物を持ち出せない。だが、社内の信頼された配達係に「これを外に出しておいて」と頼めば、警備員はその配達係を顔パスで通すかもしれない。その封筒の中に、盗んだ機密情報が入っている。
これが SSRF の基本的な構図だ。
SearchLeak では、この配達係が Bing の画像検索機能にあたる。
Copilot が出した <img> タグをきっかけに、Bing がサーバ側で画像URLを取得しに行く。そのURLの中には、Copilot がメールやファイルから見つけた機密情報が埋め込まれている。
被害者の端末が攻撃者のサーバへ直接アクセスするわけではない。Bing が、サーバ側で取りに行く。
そのため、通信先の許可リストや CSP から見ると、Microsoft / Bing という信頼済みの経路に見える。結果として、Bing が意図せず情報持ち出しの運び屋にされる。
被害者の画面に見えるのは、Copilot が一瞬「考えている」様子だけだ。データが抜かれている兆候はほとんど見えない。
ここが本記事で最も伝えたい点だ。
エンドポイント保護、URLフィルタ、アンチフィッシングは、いずれも「怪しい外部との通信」を捉える発想で作られている。だが SearchLeak には、端末から見て明確に怪しい外部通信が存在しない。
入り口は、Microsoft 365 / Copilot Search の正規URLだ。攻撃者の命令は、そのURLの検索パラメータに埋め込まれている。リンク自体は本物の Microsoft ドメインを指すため、URLフィルタやアンチフィッシングでは止めにくい。
出口は、Copilot の出力と Bing のサーバサイド取得だ。盗んだデータは、Copilot の回答生成、HTMLレンダリング、Bing の画像取得という流れの中で外へ運ばれる。被害者の端末が直接、攻撃者のサーバへ通信するわけではない。
つまり攻撃の全体が、Microsoft の信頼済み経路の中で成立している。
端末から見ると、通信相手は Microsoft / Bing だ。怪しいドメインへアクセスしているようには見えない。マルウェアが動いているわけでもない。不審な実行ファイルが落ちてくるわけでもない。
入り口は Microsoft 365 / Copilot Search の正規URL。出口は Copilot の出力と Bing のサーバサイド取得。端末から見ると、どちらも Microsoft の信頼済み経路に見える。だから EP や URLフィルタは、怪しい外部通信として捉えられない。これは検知精度の問題ではなく、監視する場所が違うという問題だ。
正直に言えば、SearchLeak は Aikido の EP / Zen / SCA / Safe Chain で直接防ぐ類の事件ではない。これは Microsoft の SaaS 内部のバグであり、防御の責任は Microsoft 側にある。そして Microsoft は、すでにバックエンド側で修正している。
ここを誤って「EPで防げる」と説明すると、論点を取り違える。問題は端末防御ではなく、AIアプリの設計境界にある。
以前、政府の生成AIガイドラインを読んだ記事で、3つの設計原則を挙げた。
SearchLeak は、この3つを破ると何が起きるかを示した実例だ。
Copilot という「新人」に、メールも社内ファイルも読める権限を与える。外から来た一言、つまりURLパラメータに含まれた命令を、そのままユーザーの指示として扱わせる。さらに、その出力がHTMLとして解釈され、外部通信を起こせる状態に置く。
結果として、悪意ある一言でその新人が操られ、社内の信頼済み経路を使って機密を持ち出してしまう。
構図は、それだけのことだ。
AI時代の脆弱性は「新しい魔法」ではない。プロンプト、HTML、SSRF、CSP、権限境界という、昔からあるWeb/AppSecの部品の組み合わせで起きる。
ただし、AIが入ることで、それぞれの部品のつながり方が変わる。検索クエリが命令になる。回答文がHTMLになる。画像取得がデータ持ち出し経路になる。正規のSaaS内部処理が、攻撃チェーンの一部になる。
古典的なバグが、AIによって再武装する。SearchLeak の本質はそこにある。
SearchLeak から、自社AIアプリやエージェントの作り手が持ち帰るべき教訓は明確だ。
AIの出力を、安全な表示物だと思い込まない。 モデルの出力は「答え」ではなく、実行され得る文字列だ。ユーザー入力を信用しないのと同じように、AIの出力も信用しない。ブラウザにそのままHTMLとして解釈させない。
検索パラメータや外部文書を、そのままプロンプトとして実行させない。 URL、メール、ドキュメント、チケット、ログ、Webページ。外部から来たデータは、すべて命令になり得る。AIに読ませる前に、どこまでをデータとして扱い、どこからを命令として扱うのかを分ける必要がある。
CSPや egress 許可リストを「安全な出口」と過信しない。 信頼済みサービス経由でデータが抜ける SSRF まで想定する必要がある。許可リストに入っている相手だから安全、とは言えない。
AIの参照権限を、利用者本人の権限に連動させる。 AIが読める範囲は、本人がアクセスできる範囲に限定する。さらに、読む、要約する、送信する、更新する、承認する、といった行為ごとに権限を分ける。
これらは AI 専用の特別な対策ではない。古典的なWeb/AppSecの規律を、AIランタイムに持ち込むという話だ。
SearchLeak は修正された。だが同じ構図の事故は、これからAIを組み込むあらゆるサービスで起こり得る。
「うちのAIは、こういう持ち出され方をしないか？」
この問いを、設計段階で一度立ててみてほしい。
Aikido Community Japan
公開日: 2026/6/16
最終更新: 2026/6/15
セキュリティの最新情報をお届けします。