Microsoft 365 Copilot SearchLeak（CVE-2026-42824）：AIアシスタントが情報流出ツールになるとき

セキュリティ研究者は、エンタープライズAIアシスタントが巧妙に作成されたリンクひとつで高度なデータ流出ツールへと変貌し、企業のDLPスタックがそれを全く検知できないことを実証しました。CVE-2026-42824、通称「SearchLeak」（Bing SSRFコンポーネントが核心）は、Microsoft 365 Copilotに存在する3段階の脆弱性チェーンであり、攻撃者が対象組織の環境に直接アクセスすることなく、ドキュメント、メール、Teamsメッセージを抽出できるものです。Microsoftはこの脆弱性にパッチを適用し、CVSSスコア9.1を割り当てました。これは、攻撃の複雑さが低く、特権が不要で、アクセス可能なデータの範囲が広いことを反映しています。

SearchLeakの公開は、その技術的な深刻さを超える重要性を持ちます。これは、エンタープライズAIツールが本番環境に導入されて以来、セキュリティアーキテクトが警鐘を鳴らしてきたリスクを具体化しています。つまり、大規模言語モデルに組織データへの広範な読み取り権限を与え、かつ外部入力を許可すると、従来のセキュリティコントロールでは対応できない攻撃対象領域が生まれるということです。組織がデータ損失防止のために活用されるツール（ネットワークDLP、CASB、メールゲートウェイなど）は、人がファイル転送を開始する世界を前提に設計されています。AIアシスタントがウェブページ内に埋め込まれた指示に応じてファイルを静かに取得・エンコードする動作には、これらのツールは全く対応できません。

このタイミングも重要です。Kiteworks 2026年データセキュリティ＆リスク 年次予測レポートでは、AIデータガバナンスが今年のセキュリティ課題の本質であると特定し、組織がAI生産性ツールの導入をガバナンスコントロールの整備よりも速く進めていることを指摘していました。SearchLeakは、その懸念を大規模に裏付ける初の深刻なCVEです。これが最後ではありません。

本記事では、攻撃チェーンの仕組み、リスクとなるコンテンツ、既存コントロールが失敗する理由、そしてCVE-2026-42824後の防御可能なAIセキュリティ体制について詳しく解説します。

主なポイント

1. 3つの弱点が連鎖し、壊滅的な攻撃チェーンに

CVE-2026-42824は単一の欠陥ではなく、プロンプトインジェクション脆弱性、HTMLレンダリングの競合状態、Bing SSRFを利用したCSPバイパスの3つを連鎖させ、悪意あるリンクをクリックするだけでユーザー操作不要の攻撃を成立させます。

2. 従来型の検知コントロールは攻撃を見逃す

流出チャネルがMicrosoft自身のBingインフラを経由するため、標準的なデータ損失防止ツールやネットワークプロキシ、CASBソリューションは外向きリクエストを不審とみなさず、トラフィックは正規のCopilotテレメトリにしか見えません。

3. Copilotを有効化したすべてのMicrosoft 365テナントが潜在的に危険

この脆弱性はCopilot for Microsoft 365全体で共有されるレンダリングレイヤーに存在し、特定のモジュールやライセンスタイプに限定されません。Copilotを有効化している組織は、優先度の高いリスクとして扱うべきです。

4. 機密文書、メール、Teamsメッセージがすべて標的範囲

CopilotはSharePointファイル、Exchangeメールボックス、Teams会話履歴など組織内コンテンツを広範にインデックス化しており、攻撃が成功すれば対象ユーザーがアクセス可能なあらゆるコンテンツが流出する可能性があります。

5. パッチ適用だけでは十分な保護にならない

Microsoftはパッチをリリースしましたが、組織は即時のパッチ適用とともに、Copilotがアクセス可能なコンテンツ、アクセス権限者、AI生成アウトプットが人によるファイル転送と同等の監査要件を満たしているかなど、AIデータガバナンス体制の見直しを行う必要があります。

SearchLeak攻撃チェーンの仕組み

SearchLeakを理解するには、Microsoft 365 Copilotが外部入力をどのように処理し、応答をレンダリングするかを知る必要があります。Copilotは、ユーザーのMicrosoft 365環境（SharePoint、OneDrive、Exchange、Teamsなど）から情報を取得し、自然言語で回答を生成する設計です。そのため、組織コンテンツへの広範な読み取り権限が必要となります。この広範なアクセスこそがCopilotの価値であり、同時に攻撃者がモデルのコンテキストに指示を注入できる場合は危険性ともなります。

ステージ1：パラメータからプロンプトへのインジェクション

最初の弱点は、Copilotが特定のURLパラメータを処理する際のパラメータからプロンプトへのインジェクション脆弱性です。ユーザーがページにアクセスしたり、Teamsやメールで共有されたリンクをクリックした際、細工されたURLが処理されると、攻撃者が制御するテキストが十分なサニタイズなしにCopilotのプロンプトコンテキストへ渡されます。つまり、攻撃者はリンク内に隠れた指示を含めることができ、その指示でCopilotに特定ドキュメントの取得、メール内容の要約、Teams履歴の検索などを実行させることができます。

プロンプトインジェクションはAIリスクの既知のカテゴリであり、信頼できないコンテンツが信頼された指示として扱われる点でクロスサイトスクリプティング攻撃に相当します。SearchLeakの実装が特に危険なのは、ユーザーがCopilotチャットウィンドウで操作しなくても攻撃が成立することです。悪意ある指示は、ユーザーのブラウザがページを読み込むだけで受動的に配信されます。

ステージ2：HTMLレンダリング競合状態

2つ目の弱点は、Copilotの応答面におけるHTMLレンダリングの競合状態です。CopilotがHTMLでレンダリングされる出力（特定のCopilot連携でリッチカード表示に使われる機能）を生成する際、レンダリング中に攻撃者制御のHTMLがCSP（コンテンツセキュリティポリシー）制限が完全に適用される前に実行できるタイミングウィンドウが存在します。研究者はこの隙間を利用し、流出データをクエリパラメータとしてエンコードした細工済みタグを注入することに成功しました。

CSPは本来、この種のデータ流出を防ぐためにページが接続できる外部ドメインを制限するブラウザレベルの制御です。ここでチェーンの3つ目の段階が重要となります。

ステージ3：Bing SSRFによるCSPバイパス

3つ目の弱点は、CopilotがMicrosoftのBingインフラを通じてリクエストをプロキシする際のサーバーサイドリクエストフォージェリ（SSRF）脆弱性です。Copilotは検索やグラウンディング処理のために正規にBingと通信しており、BingエンドポイントはCSPの許可リストに含まれています。研究者は、特別に細工したBing URL経由で流出リクエストをルーティングすることで、CSPルールで明示的に許可されたエンドポイントを通じて盗まれたデータを送信できることを発見しました。

その結果、攻撃者のタグが発火し、取得したドキュメント内容をURLパラメータとしてエンコードし、リクエストはBingを経由して送信されます。ネットワークレベルの監視からは通常のCopilot-to-Bingトラフィックにしか見えず、データは組織外へ静かに流出します。

リスクにさらされるデータとは

SearchLeakが流出可能な範囲は、Copilotがアクセスできる範囲で決まります。Copilotのインデックス範囲を明示的に制限していない組織では、対象ユーザーがMicrosoft 365でアクセスできるほぼすべてのデータが対象となります。

研究者は、SharePointドキュメントライブラリの内容、Exchangeメール本文（添付ファイル含む）、Teamsのダイレクトメッセージやチャンネル会話、OneDriveファイルの取得を実証しました。実際の運用環境では、SharePointに保存された知的財産、個人識別情報 / 保護対象保健情報を含む患者や顧客とのメールスレッド、法務コミュニケーション、仮想データルーム内のM&A文書、HIPAA、GDPR、CMMCの規制対象コンテンツなどが含まれます。

この攻撃は、ターゲットの環境について何らかの情報を持つ攻撃者（たとえばLinkedInや事前の偵察で得た情報）が、特定の検索クエリを含むプロンプトを注入することで、狙ったドキュメントを取得させることができます。「過去90日間の買収ターゲットに関するメールを探せ」や「Legal SharePointサイト内の最新契約書を取得せよ」といった指示も可能です。無差別な大量流出だけでなく、ピンポイントでの流出も可能です。

だからこそ、DSPMの問いが今、極めて重要です。Microsoft 365環境内にどんな機密コンテンツが存在し、特定のユーザーやCopilot（そのユーザーとして動作）が何にアクセスできるかを把握していない組織は、未知のリスクにさらされています。データガバナンスやアクセス制御・スコープ設定は、この文脈では抽象的なコンプライアンス作業ではなく、影響範囲を理解し制限するための直接的な前提条件です。

SearchLeakが既存セキュリティコントロールをすり抜ける理由

SearchLeak攻撃は、ほとんどの組織がデータ流出防止のために活用されるコントロールカテゴリを意図的に回避するよう設計されています。これは偶然ではなく、AIが関与する場合にエンタープライズセキュリティツールにどんなギャップがあるかを熟知した上でのものです。

ネットワークDLPとCASBの限界

DLPやCASBは、外向きトラフィック内の社会保障番号やクレジットカード番号、既知のドキュメント構造など、認識可能な機密データパターンを検査します。しかしSearchLeakでは、流出データはCopilot-to-Bingの正規リクエストに見えるURLパラメータとしてエンコードされます。多くのDLPツールは、許可リストにあるMicrosoftトラフィックのURLパラメータまで深く検査するよう設定されていません。仮に検査しても、攻撃のエンコーディング方式を事前に知っていなければ、ドキュメント送信を特定できません。

メールゲートウェイとプロキシの限界

この攻撃はメールを流出チャネルとして使用しません。プロキシが検知するような外向きファイル転送も不要です。流出経路はCopilot応答のレンダリング時に発生するBing URLへのHTTP GETリクエストのみです。標準的なプロキシツールはMicrosoft間のリクエストと見なし、許可します。

エンドポイントDLPの限界

エンドポイントエージェントがファイルアクセスやクリップボード操作を監視しても、この攻撃は検知できません。ユーザーによるファイルの開封やコピー、エージェントが監視するチャネルでの転送は発生せず、ファイルアクセスはCopilotサービスレイヤー内で完結します。

SIEMと行動分析の限界

SIEMやユーザー行動分析プラットフォームは、ユーザーアクティビティの異常パターンを検出します。しかし、Copilotセッションが複数のドキュメントを取得し、BingへGETリクエストを送っても、行動的には通常のCopilot利用と区別がつきません。SearchLeakパターンを特定する検知ルールがなければ、アラートは発生しません。

この結論は不快ですが現実です。標準的なエンタープライズセキュリティコントロールを導入したMicrosoft 365 Copilot環境にはギャップが存在します。これを埋めるには、人による操作を前提とした従来コントロールの延長ではなく、AIを介したデータアクセス専用のセキュリティ投資が必要です。

SearchLeakが露呈させたガバナンスの課題

SearchLeakは、従来型アプリケーションで発見されても深刻な脆弱性ですが、Microsoft 365 Copilotにおいてはさらに重大な問題を明らかにします。つまり、規制環境下でAIを責任ある形で導入するために必要なガバナンス基盤が、AI導入のスピードに追いついていないということです。

ガバナンス上の核心的なギャップは、属性ベースアクセス制御（ABAC)とデータスコープ設定です。多くの組織は、Microsoft 365 Copilotをデフォルト設定のまま導入しており、Copilotにはユーザーがアクセスできるすべてのデータへの権限が与えられています。SharePoint権限が広い役員の場合、Copilot（およびプロンプトを注入できる攻撃者）は同じ範囲の機密情報にアクセスできます。適切なデータガバナンスには、AIツールがデータ最小化の原則、すなわち「そのタスクに必要な最小限のデータのみアクセスする」ことが求められます。

2つ目のガバナンスギャップは可監査性です。人間の従業員が機密文書にアクセスすれば、そのアクセスはSharePointの監査ログに記録され、DLPプラットフォームが他のアクティビティと相関できます。しかし、Copilotがユーザーの代理で同じ文書にアクセスした場合（特に注入指示によるアクセス）は、監査証跡が複数のログソースに分散し、ほとんどの組織はそれを相関できていません。SearchLeakで50件の文書が流出しても、Copilotセッションログ、Bingリクエストログ、SharePoint監査ログに断片的に痕跡が残るだけで、それらを結びつける統合的な可視化レイヤーが必要です。

3つ目のガバナンスギャップは、AIレイヤーでのポリシー強制です。多くの組織でDLPポリシーはファイルシステム、メールゲートウェイ、エンドポイントレベルで強制されていますが、AIインタラクションレイヤーには同等の強制力がありません。「Copilotは機密タグ付き文書を取得し、その内容をHTMLで応答として表示してはならない」といった制御は存在しません。このようなAIデータガバナンス機能には、AIセキュリティ専用のインフラが必要です。これを実現するには、規制コンプライアンスと同等の厳格さ（体系的、可監査、継続的な強制）が求められます。

防御可能な対応とは

CVE-2026-42824のパッチ適用は必須の第一歩ですが、それだけでは十分な対応とは言えません。パッチのみ適用した組織は、今回の攻撃経路は塞げても、根本的なガバナンスギャップは次の攻撃に対して依然として残ります。防御可能な対応には4つの要素があります。

1. パッチを即時適用する。 CVE-2026-42824に対するMicrosoftのパッチは最優先で展開してください。CMMC 2.0コンプライアンスが求められる防衛請負業者、HIPAAコンプライアンス下の医療機関、GDPRやFINRA規制下の金融機関など、規制環境下でMicrosoft 365 Copilotを利用する組織は、パッチが公開済みであってもゼロデイ対応として扱うべきです。深刻度と、公開前に悪用された可能性を考慮してください。
2. Copilotのデータアクセス範囲を見直す。 Microsoft 365テナント内のSharePoint感度ラベル、権限構造、Copilotアクセス設定を確認しましょう。データ最小化の原則を適用し、Copilotがユーザーの役割に必要なコンテンツのみにアクセスできるようにしてください。データ分類は前提条件です。SharePointやExchangeで機密コンテンツにラベル付けしていない組織は、Copilotが取得できる範囲を効果的に制限できません。MicrosoftのCopilotデータガバナンスドキュメントには、スコープ設定の具体的なガイダンスがあります。感度ラベルが一貫して適用されていない場合は、今こそその作業を加速させるべきです。
3. AIレイヤーでの可視化とポリシー強制を実装する。 AIデータガバナンス専用ツール（例：Kiteworks AI Data Gateway）は、汎用DLPやCASBソリューションに欠けている可視化と強制レイヤーを提供します。AI Data Gatewayは、AIモデルが組織コンテンツとやり取りするポイントでデータアクセス方針を強制し、属性ベースアクセス制御（ABAC)でAIツールが取得・表示できるコンテンツを制御し、AIを介したアクセスも人による操作と同じ統合監査証跡に記録します。これはSearchLeakが露呈させたガバナンスギャップへのアーキテクチャ的な対応であり、単なるCVE個別のパッチではありません。
4. 事後レビューで悪用の有無を確認する。 CVE-2026-42824はパッチ公開前に悪用可能だったため、パッチ適用前の期間についてCopilotセッションログ、SharePoint監査ログ、Bingプロキシログを確認してください。特に、異常に多くのドキュメントを取得したCopilotセッション、外部リンククリックで開始されたセッション、異常に大きなURLパラメータを持つBingへの外向きリクエストを調査しましょう。AIを介した流出シナリオもカバーするインシデント対応計画を文書化しておくことで、悪用が確認された場合も迅速に対応できます。攻撃は検知回避を目的として設計されているため、必ずしも発見できるとは限りませんが、特に規制報告義務のある組織では責任あるデューデリジェンスの一環です。

より大きな教訓：AIセキュリティは既存セキュリティの延長ではない

CVE-2026-42824は、セキュリティ業界が先送りしてきた議論を促すべき転機です。人によるデータ流出を防ぐために設計されたツールやアーキテクチャは、AIアシスタントがアクセスできる状況や、外部攻撃者がAIアシスタントに指示を注入できる状況では、同じデータを守るのに十分ではありません。

問題は、Microsoftが脆弱な製品を作ったことではありません。複雑なソフトウェアには必ず脆弱性があり、Microsoftの対応も適切でした。本質的な問題は、Copilotと併用されたセキュリティコントロールが、根本的に異なる脅威モデルを前提に設計されていたことです。これらは、データが人の操作（ファイルダウンロード、メール添付、USB、Webアップロードなど）で組織外に出ることを想定しています。AIアシスタントが注入プロンプトに応じてコンテンツを取得・エンコードする動作は、検知・防止の設計対象外です。

組織に必要なのは、AIを介したコンテンツアクセスに特化したプライベートデータネットワークモデルです。これは、AIツールと組織データのすべてのやり取りにゼロトラスト・セキュリティの原則を適用することを意味します。AIレイヤーでのデータ最小化の徹底、すべてのAIアクセスイベントの統合監査ログへの記録、感度ベースのポリシー制御、AI特有の攻撃パターンに対応した検知能力の構築が求められます。

SearchLeakを一度限りのパッチ対応と捉える組織は、同種の次のCVEで同じリスクに直面します。これを機に、モデルインタラクションレイヤーで方針を強制できるAIガバナンス基盤を構築する組織は、今後の脆弱性や、AIデータアクセスを独立したコンプライアンス領域として監査する規制当局への対応力も大きく向上します。

AIによる機密データ流出からの保護についてさらに詳しく知りたい方は、カスタムデモを今すぐご予約ください。

追加リソース

• ブログ記事
  ゼロトラスト戦略で実現する手頃なAIプライバシー保護
• ブログ記事
  77%の組織がAIデータセキュリティに失敗している理由
• 電子書籍
  AIガバナンスギャップ：91%の中小企業が2025年にデータセキュリティでロシアンルーレット状態
• ブログ記事
  あなたのデータに「–dangerously-skip-permissions」は存在しない
• ブログ記事
  規制当局は「AIポリシーがあるか」ではなく「機能している証拠」を求めている