Azure MCP ServerのSSRFにより、マネージドIDトークンがURLへ漏洩する可能性

Microsoftは2026年3月10日にCVE-2026-26118を公開しました。これはAzure MCP Server Toolsにおけるサーバーサイドリクエストフォージェリの脆弱性です。同パッケージは、AIエージェントやMCPクライアントが自然言語でAzureリソースを操作できるようにします。MCPベースのエージェントとやり取りできる攻撃者は、通常のAzureリソース識別子の代わりに悪意のあるURLを送信でき、サーバーはそのアドレスに外向きリクエストを送信し、Microsoftの言葉を借りれば「マネージドIDトークンを含める可能性がある」ため、その結果、呼び出し元に本来見せるはずのない資格情報を渡すことになります。Microsoftはこの脆弱性をCVSS 8.8と採点してImportantと評価し、修正を含むパッケージは1.0.2および2.0.0-beta.17です。アドバイザリには悪用やパッチ前の公開開示は記録されておらず、実際の被害も記録されていません。このインシデントは「Orca AI Incident Archive」の1件であり、同アーカイブには引用元、重大度評価、信頼度評価を含む完全な記録が収められています。

その勧告が実際に述べていること

Microsoft Security Response Centerの記録は簡潔で、この脆弱性について公開されているほぼすべての詳細は、この記録、または少数の追加質問に対するMicrosoftの回答に由来している。説明の全文は次のとおり。「Azure MCP Serverにおけるサーバーサイドリクエストフォージェリ（SSRF）により、認可された攻撃者がネットワーク経由で特権を昇格できる」。CVEレコードは2026年2月11日に識別子を予約し、3月10日14:00 UTCに公開した。MicrosoftのリリースノートとNVDのエントリはいずれもその日付を記載している。NVDはその記録を分析し、同日午後18:18 UTCに公開した。本記事で確認された規制当局の通知は1件のみで、モロッコのものだった。DGSSIのmaCERT部門は、2026年3月11日付の bulletin にCVE-2026-26118を掲載し、影響を受ける製品にAzure MCP Server Toolsを挙げ、独自のリスクレベルを「Important」とし、個別のスコアは示さず、Microsoftのリリースへの参照先を示していた。

この弱点はCWE-918（サーバーサイドリクエストフォージェリ）にマッピングされており、影響の分類は特権昇格です。Microsoftの基本スコアは、ベクターCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hで8.8、時間的スコアはE:U/RL:O/RC:Cで7.7です。E:Uはスコア設定時にMicrosoftがエクスプロイトコードを把握していなかったことを意味し、RL:Oは公式修正が利用可能だったことを意味します。NVDも同じ基本スコアを採用してHighに分類しており、Microsoft独自の3段階尺度ではImportantとされています。

スコアと同じくらい重要な項目が2つある。Microsoftの記録では悪用: なし、および公開: なしとなっている。NVDエントリに関するCISAのSSVC決定記録（2026年3月5日のタイムスタンプ付き）も悪用については—なし—と一致し、一方で技術的影響は全面的、自動化可能はいいえと判断している。FIRST EPSSモデルは、2026年11月3日付の取得データで、今後30日以内の悪用確率を約1.0%、62.8パーセンタイルと算出した。これは発見され修正された脆弱性であり、実際に悪用されたことが知られているものではない。

リソース識別子がアウトバウンドリクエストになる仕組み

Azure MCP Server は、AI エージェントがツールを呼び出すためのインターフェースである Model Context Protocol の Microsoft による実装です。そのツールは、エージェントが指定するパラメーター — ストレージ アカウント名、サブスクリプション識別子、データベース名 — を受け取り、Azure の管理プレーンおよびデータ プレーンに対する呼び出しに変換します。Microsoft のドキュメントでは、このサーバーは「Azure ユーザー資格情報またはマネージド ID」を使用して Entra ID 経由で認証し、アクセスは Azure のロールベースのアクセス制御によって制限されると説明されています。

この欠陥は、Azure リソースを指定すべきパラメーターが、代わりに URL として受け入れられてしまう点にあります。Microsoft 自身の説明によると、攻撃者は「ユーザー提供のパラメーターを受け入れる Azure Model Context Protocol (MCP) Server ツールに特別に細工した入力を送信することで、この問題を悪用できる可能性があります。攻撃者が MCP を基盤とするエージェントと対話できる場合、通常の Azure リソース識別子の代わりに悪意のある URL を送信できます」。その後、サーバーはツールが意図した宛先ではなく、指示された宛先へリクエストを送信します。

厄介な問題を特権昇格に変えるのは、一緒に運ばれるものです。Microsoft によると、送信要求には「そのマネージド ID トークンが含まれる場合があり」、これにより攻撃者は「管理者アクセスを必要とせずに」そのトークンを取得できます。マネージド ID トークンはベアラー資格情報です。保持している者は誰でも、有効期限が切れるまで、その ID が承認されている Azure サービスにそれを提示できます。同じ段落の緩和側の部分も同じくらい重要です。攻撃者は「MCP サーバーのマネージド ID に関連付けられた権限」を取得し、Microsoft の言葉を借りれば「テナント レベルや管理者のより広範な権限を得ることはなく、侵害されたマネージド ID に紐づく権限のみを得る」のです。影響範囲は、誰かがその ID に付与した権限の範囲であり、実際には単一のツールに必要だった以上の権限であることがよくあります。

マイクロソフトは影響を受けるツールやパラメータを名指ししておらず、この記事のために確認したどの情報源も名指ししていない。その省略自体が一つの詳細である。勧告は単一のエンドポイントではなく、ユーザー提供のパラメータを受け取り、URLを取得するよう誘導され得るツールのクラスについて説明している。

修正と、それを含むパッケージ

これはWindows Updateではありませんでした。Azure MCP Server Toolsは、.NET向けのNuGetパッケージ、npmパッケージ、およびPyPI上のPythonパッケージとして提供されており、修正はデプロイが使用するいずれかのパッケージでバージョンを上げることです。Microsoftのアドバイザリでは、影響を受ける範囲をNuGet、npm、PyPIの各配布物全体で、1.0.0以上1.0.2未満、および2.0.0-beta.1以上2.0.0-beta.17未満としています。

npm レジストリの日付を見ると、修正済みビルドがアドバイザリより前にレジストリに存在していたことがわかります。バージョン 1.0.2 の@azure/mcp は 2026年3月6日に公開され、CVE が公開される4日前でした。2.0.0-beta.17 は 2026年2月6日に公開され、Microsoft が CVE 識別子を予約した5日前、アドバイザリが公表される1か月前でした。Microsoft 内部の順序がどうであれ、修正済みコードは公開日に合わせて書かれたものではありません。NVD と GitHub のアドバイザリデータベースは、これらの上限について一致しています。PyPI 範囲の下限では少し食い違っています — NVD は 2.0.0-beta.1、GitHub のアドバイザリは 2.0.0b14 としています — この不一致は公開時から両レコードが抱えているもので、Python デプロイがどこまで遡って確認する必要があるかにのみ影響します。

アドバイザリ自体は公開から10日後の2026年3月20日に改訂され、Microsoftが「Azure MCP Server Tools の提供に使用されるさまざまなパッケージ方法を記載した製品を Security Updates テーブルに追加した」との注記が付けられた。言い換えれば、アドバイザリの最初の版では製品名は示されていたが、提供されたすべてのチャネルまでは示されておらず、これは修復が「この KB をインストールする」ではなく「パッケージをアップグレードする」場合に重要となる。

確立されていないものは何か

誰が発見したのか。Microsoft のアドバイザリにも CVE.org の記録にも報告者の名前は記載されていません。CVE のクレジット欄は空です。これは、誰も非公開でクレジットされなかったという証拠ではなく、公開されたクレジットが存在しないというだけのことです。

悪用の事実は一切ありません。Microsoftは何も記録しておらず、CISAのSSVC評価も同様の見解を示しており、本記事のために調査したどの情報源も、実際の環境で侵害されたIDについて言及していません。記録の実害フィールドがfalseであることも、これと整合しています。EPSSの低さは予測であって調査結果ではなく、インシデントが報告されていないことは、何も発生しなかったことの証明にはなりません。

公開されたエクスプロイトが存在するかどうか。 ここで二次情報の見解が分かれる。Blueinfyのブログの2026年3月の投稿は、「GitHub上のものなど、公開された概念実証エクスプロイトが存在する」と述べ、「急速な兵器化」を警告しているが、リンク、ペイロード、手順のいずれも示しておらず、その脆弱性を実証してもいない。Microsoftの記録によれば、この脆弱性はパッチ適用前に公開開示されていなかった。2026年11月4日にCVE識別子でGitHubリポジトリを検索したところ、1件のリポジトリが返された。それは2026年3月17日に公開されたMicrosoft Sentinelの検出ラボであり、エクスプロイトではなかった。またMalloryの脆弱性ページには、2件の候補エクスプロイトが審査され却下されたと記載されている。利用可能な証拠に基づけば、実際に動作する公開エクスプロイトコードが存在するという主張は裏付けられておらず、誰も試みていないという主張も同様に証明されていない。

論調。ベンダーのインシデント概要サイトであるPolicyLayerのページは、CVE-2026-26118を、完全なテナント乗っ取りに至る未認証のリモートコード実行チェーンとして再構成し、名前の挙げられた研究者とRSAC 2026でのデモに帰している。そのページ自身が引用する資料のタイトルはSSRFとなっており、その日付はCVEのタイムラインと整合せず、MicrosoftのアドバイザリもSecurityWeekの3月10日の報道もコード実行について述べていない。本記事はSSRFとトークンに関する説明を確立したものとして扱い、RCEという論調を繰り返さない。

なぜリクエストではなくトークンが指摘事項なのか

サーバーサイドリクエストフォージェリは、Webソフトウェアにおける最も古い種類のバグの一つであり、それ単体では通常、攻撃者が直接アクセスできないシステムに到達するための手段です。この記録が残す価値があるのは、リクエストに付随する資格情報です。MCPサーバーは設計上、混同代理（confused deputy）です。つまり、エージェントがユーザーの代理として行動できるようにアイデンティティを保持しており、エージェントが渡すすべてのパラメーターは、サーバーから見れば攻撃者の影響を受けたテキストです。そうしたパラメーターの一つが名前ではなく宛先になったとき、その代理は自身の認可を宛先まで運びます。

マイクロソフトのドキュメントは、そのリスクがどこに集中するのかをより明確にしている。ローカルサーバーについては「組織内での開発者による使用に厳密に限定される」と説明する一方で、Microsoft Foundry と Copilot Studio における自己ホスト型リモートサーバー向けのデプロイガイドを別途公開している。これらの構成では、開発者自身のサインインではなく、通常はマネージド ID が使用される資格情報となる。このアドバイザリのトークン窃取の経路は、具体的にはマネージド ID に関するものだ。すべてのインストールが露出していたとは述べておらず、その数についても述べていない。

一般的な教訓は、OWASPのAIセキュリティ検証標準（AISVS）が今やこの事例を用いて教えている教訓である。AISVSのオーケストレーションの章は、実例の一つとしてCVE-2026-26118を挙げ、次のような結論を導いている。「MCPツールのパラメータは攻撃者が制御し得るものとして扱わなければならず、MCPサーバーからの外向きリクエストは、他のあらゆるエージェント駆動型I/Oに期待されるのと同じ外向き通信（egress）およびオリジンポリシーを通過させなければならない」。これは対策の推奨であり、本件に関する発見事実ではないが、何を変えるべきかという問いに対して誰かが公開した最も具体的な回答である。

その後、何が変わりましたか

三つのこと、そしてそのどれも劇的ではない。マイクロソフトは三つのエコシステムすべてで修正パッケージを出荷し、勧告を改訂してそれらを明記した。脆弱性インテリジェンスのエコシステムはそれを静かに取り込んだ。低いEPSSスコア、そして2026年6月17日に最終更新されたNVDレコードである。そして標準化コミュニティはそれを教材として採用した。これはパッチよりも遅く、より持続的な対応の形である。

影響を受けるビルドをまだ実行している人にとって、修復方法は変わらず、地味なものです。デプロイが関与するすべてのパッケージマネージャーで、安定版系列なら 1.0.2 以降、プレビュー系列なら 2.0.0-beta.17 以降に移行してください。さらに、アドバイザリ自体の論理からは 3 つの制御が示唆されます。サーバーがアウトバウンドで到達できる範囲を制限すること、マネージド ID にはそのツールが実際に必要とするロールだけを付与すること、URL になり得るツールパラメーターはすべて敵対的入力として扱うことです。これらのいずれも、CVE-2026-26118 を生き延びるために必須だったわけではありません。どれか一つを実施するだけでも、次に挙げる制御の攻撃者にとっての価値は下がるはずです。

アーカイブがこれをどう分類するか

この記録は、悪用されたことが知られているものではなく、発見されたものとして脆弱性に分類されており、信頼度はA評価、つまり一次資料が一致する十分な文書化がなされていることを意味し、異議ありとも記されていない。実害フィールドはfalseで、AI関与は確認済みである。影響を受ける製品が、たまたま近くにある汎用サービスではなく、AIエージェントとクラウド制御プレーンをつなぐ橋渡し役だからである。日付は日単位の精度で2026年3月10日と記録され、終了日はない。これはキャンペーンではなく単一の時点だからである。地域はグローバルで、ランドマークフラグはfalseである。

1つのフィールドは、公開されているスコアリングとは異なる内容を示している。アーカイブの重大度は独自の尺度で medium と記録されている。Microsoft と NVD の両方が公開している数値は 8.8 で、Microsoft はこれを Important と呼び、NVD は High に分類している。レコードの概要は冒頭でその 8.8 を示しており、この不一致は事実の違いではなく、バケット分けの違いである。

記録からは伝わらないが、この話の大部分は不在だ。誤った形で要求する者にクラウドアイデンティティを渡してしまう欠陥がある。修正は存在し、告知より前に出荷されていた。発見者はクレジットされておらず、名前の付いたツールもなく、悪用も確認されておらず、外部の者が、強力なアイデンティティを保持したまま脆弱なビルドを実行したホステッドデプロイがかつてあったかどうかを知る術もない。勧告は欠陥が何をするかについては正確で、それ以外のほとんどすべてについては沈黙している。そしてその沈黙こそ、この件で気づくべき最も有用なことだ。