Azure SRE Agentの9.9の認可脆弱性により、呼び出し元がそのIDを継承できる可能性があった

CVE-2026-62830は、Azureのサイト信頼性チーム向けにMicrosoftが提供するAI搭載エージェント「Azure SRE Agent」における認可の欠落の脆弱性です。このエージェントはインシデントをトリアージし、テレメトリを照会し、構成されている場合には修復を実行します。Microsoftは2026年8月にこれを公表し、CVSS 3.1で10点満点中9.9点——Critical——と採点しました。このエージェントを実行しているAzureテナントはすべてこのバグの影響範囲に含まれていましたが、インシデントアーカイブには確認済みの被害者も悪用も記録されていません。Microsoftによるこの脆弱性の説明は1文です。「Azure SRE Agentにおける認可の欠落により、認可された攻撃者がネットワーク経由で特権を昇格できる」。サービスはサーバー側で修正され、Microsoftは顧客にパッチを当てる必要はなかったと述べています。重大度と信頼度の格付けを含む完全なエントリは、Orca AI Incident Archive内で、このシリーズの隣接するインシデントと並んで掲載されています。

Microsoftが公開したこと、そして公開しなかったこと

MicrosoftのSecurity Update GuideにおけるCVE-2026-62830の項目には、Azure SRE Agentにおける特権の昇格、弱点CWE-862（Missing Authorization）、基本スコア9.9、一時スコア8.6が記録されています。ベクター — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C — は、低い権限のみを必要とし、ユーザー操作を伴わず、機密性・完全性・可用性に高い影響を及ぼすネットワーク攻撃を示しています。Microsoftは、アドバイザリの謝辞において、この発見をOffensiのセキュリティ研究者wtmによるものとしています。

そのベクターの2つの部分がこの話の鍵を握っています。スコープ指標はChanged (S:C)で、Microsoft自身のメトリックドキュメントでは、脆弱なコンポーネントと影響を受けるコンポーネントが異なり、それぞれ異なるセキュリティ管理主体によって管理されているケースと定義されています。時間的メトリックはUnproven exploit code、Official fix、Confirmedであり、そのため時間的スコアはベースを下回っています。

アドバイザリのFAQでは、ダウンロードリンクのない9.9がなぜ存在するのかを次のように説明しています。「この脆弱性はMicrosoftによってすでに完全に緩和されています。このサービスのユーザーが取るべきアクションはありません。このCVEの目的は、さらなる透明性を提供することです」。Microsoftはこの製品を専用のホスト型サービスとして分類しているため、このエントリにはビルド番号も影響を受けるバージョン範囲も記載されていません。

悪用可能性の表は FAQ と同じくらい明確です。公開済み: いいえ。悪用済み: いいえ。悪用評価: 可能性は低い。アドバイザリが説明していないのは、on-behalf-of フロー、マネージド ID、ランブックです。バージョン範囲も示していません。CPE はバージョンなしの製品であり、影響を受けるバージョンとして記載されているのはダッシュだけです。読者がこのメカニズムについて知りたいことはすべて別のところから得るしかなく、その別のところとは主にアーカイブ自体のエントリです。

エージェントとは何か、そしてなぜそのアイデンティティこそが到達する価値のあるものなのか

Azure SRE Agent は、ダッシュボードに後付けされたチャットボットではありません。マイクロソフトの Azure SRE Agent ドキュメントでは、Azure リソース、可観測性ツール、インシデント対応プラットフォーム、ソースコード リポジトリに接続し、シグナルを収集し、デプロイを関連付け、緩和策を提案し、顧客が設定した実行モードに応じてそれらを実行するエージェントについて説明しています。レビュー モードでは管理者が書き込みアクションを承認します。自律モードでは、エージェントは待機せずにそれらを適用します。その機能範囲は、スキルとランブック、Azure CLI 操作、カスタム エージェント、Python ツール、MCP コネクタ、エージェント フックを通じて拡張されます。

同じドキュメントには、この CVE を興味深いものにする事実が記されています。「エージェントはマネージド ID で認証し、Azure のロールベースのアクセス制御（RBAC）の下で動作します」。マネージド ID はサービスに割り当てられた Entra の ID であり、それが実行できることは、そのロール割り当てが許可する内容にほかなりません。したがって、エージェントの権限はエージェントのコードの属性ではなく、その ID に付与されたロールの属性です。そしてそれは、認可チェックが欠落していれば保護に失敗する境界です。

Azure SRE Agentの権限昇格に関するHackTricks Cloudの項目は、CVE-2026-62830を引用せずに、この問題の構造的な側面を説明した別個の技術解説です。そこには、呼び出し元がエージェントを操れるコントロールプレーン操作——スレッドを開く、提案された修復を承認する、エージェントの設定を再バインドする、データコネクタの参照先を変更する——が列挙され、その結果を混乱した代理人（confused deputy）として位置づけています。呼び出し元はエージェントの権限を必要とせず、エージェントにそれを使わせる手段だけを必要とする、というわけです。この項目は本CVEに関するものではなく、本CVEの裏付けとして読むべきではありません。スコアが有用であるのと同じ理由で有用です。つまり、権限が実際にどこにあるのかを示しているのです。

仕組み：アーカイブが記述している内容と、ベンダーが確認している内容

アーカイブの項目では、この欠陥を、同項目が Scope-Changed OBO（on-behalf-of）フローと呼ぶものにおける失敗として説明している。on-behalf-of フローとは、あるサービスが呼び出し元の資格情報を、その呼び出し元としてダウンストリーム サービスを呼び出せるトークンに交換するトークン交換である。アーカイブによると、その交換時の権限チェックが失敗すると、ダウンストリーム呼び出しは呼び出し元の ID ではなく、エージェント自身のテナントスコープのマネージド ID にフォールバックできる。そうなると、低権限だが認証済みの呼び出し元がエージェントのサービス プリンシパルのアクセス許可を継承し、ランブック、テレメトリ、インフラストラクチャを変更できてしまう——エージェントだけでなく、そのマネージド ID がロールを保持するすべての Azure リソースが対象になる。

その記述は、Microsoft が実際に公開したすべての内容と整合しており、Microsoft が公開した内容の中には含まれていません。ベンダーの文書は次の3点を裏付けています。認可チェックが欠落していたこと、呼び出し元に必要な権限が低いこと、影響がセキュリティ権限の境界を越えることです。トークン交換、ID 継承、ランブックとテレメトリの例については裏付けていません。アーカイブのエントリがそれらの出典であり、アーカイブはベンダーではなく二次データセットです。

独立した報道を探しても、同じ段落が複数の場所で見つかるだけです。OBOフローとブラスト半径に関する見出しは、とりわけforkast.newsやYahoo Techなどにシンジケート配信されているようです。シンジケート配信によって、その報道は複数の情報源ではなく一つの情報源になります。この記事のために検討したどの媒体も、独自のテレメトリー、実証実験、あるいはこの仕組みの再現を公開していません。

何が確立され、何が記述され、何が決して主張されなかったのか

アーカイブはこの記録をAと評価しており——十分に文書化され、一次資料も一致している——論争中とは記していません。現実世界での害は記録していません。この評価は記録の中核的な事実に関するものであり、それらは資料間で確かに一致しています。これは、項目内のすべての文が独立に再現されたという主張ではありません。

• ベンダーにより確認済み。 CVE-2026-62830 は Azure SRE Agent に影響し、CWE-862 の認可欠如に該当し、CVSS 3.1 の基本スコアは 9.9、時間スコアは 8.6 で、顧客による対応は不要でした。公開されていません。また、悪用された記録もありません。

• 独立したセキュリティ報告およびエンリッチメントによって確立されています。Cisco Talosの2026年8月のPatch Tuesdayまとめでは、同じ9.9と同じ認可欠如の弱点を持つCVEが記載され、Microsoftの「悪用される可能性は低い」という評価の下に置かれています。NVDを通じて記録されたCISAのSSVC評価では、悪用はなし、自動化可能はいいえ、技術的影響は全面的と評価されています。OpenCVEのエンリッチメントにはEPSSスコア0.00778が記載され、このCVEがCISAのKnown Exploited Vulnerabilitiesカタログに含まれていないことが記録されています。

• 記述されているが、独立して確認されていない。 OBO トークン交換の失敗、エージェントのマネージド ID の継承、およびランブック、テレメトリ、インフラストラクチャへの影響は、アーカイブの項目とシンジケート配信された二次報道に由来する。Microsoft のアドバイザリはこれらを名指ししていない。これらは記録の中で最も有用な部分であり、最も文書化が不十分な部分でもある。

• どこにも確立されていない。悪用なし、被害者なし、公開された概念実証なし、ビルド番号も影響を受けるバージョン範囲もない。Microsoftの悪用可能性に関する記載——公開: いいえ、悪用: いいえ、可能性は低い——が、存在する状況報告に最も近いものだ。

• 主流メディアの報道はありません。このCVEを一般技術系およびセキュリティ系メディアで検索しても、The Register、BleepingComputer、SecurityWeek、Help Net Securityの記事は一切見つかりませんでした。公開されている情報は、ベンダーのアドバイザリ、脆弱性データベース、Patch Tuesdayのまとめ記事、およびシンジケート配信記事のみです。9.9としては異例であり、これはリスクについての判断ではなく、記録に関する事実です。

修正と、それよりも長く生き残るチェック

Azure SRE Agent はホスト型サービスであるため、修正は Microsoft 側で適用されました。インストールする更新プログラムも、インベントリと照合するビルド番号もなく、顧客が外部から、特定の日付より前にテナントが保護されていたことを確認する方法もありません。Microsoft の立場は、アクションは不要というものであり、脆弱性自体についてはその立場は正しいです。

アーカイブのエントリには、勧告では明記されていないガイダンスが追加されています。マネージド ID の割り当てを監査し、エージェントが実際に必要とする内容に照らして RBAC を確認し、異常な特権昇格を監視することです。このガイダンスはアーカイブによるものであり、Microsoft からの引用ではありません。

実務上の帰結は、どの情報源の推奨事項からではなくアーキテクチャから生じるため、推論として扱ってください。エージェントの権限がそのロール割り当てである場合、持続的な統制となるのは、それらの割り当てのスコープと、それらが使用されていることを示すコントロールプレーン ログの保持です。サービス側の修正は経路を塞ぎますが、過剰にプロビジョニングされたマネージド ID を遡って狭めるわけではなく、ログを保持していなかった組織を助けることもできません。これらはいずれも、CVE がクローズされた後も顧客が依然として担う事項です。

2026年8月のバッチでの位置づけ

タロスのまとめを見れば、その比較は避けられない。その月のまとめには、Copilot CoworkにおけるCVE-2026-59118（不適切な認可を通じた権限昇格、スコア9.3）と、Azure SQL DatabaseにおけるCVE-2026-56162（権限昇格、スコア10.0）も記載されている。その月にタロスが実際に悪用されていると報告した脆弱性は、これらのどちらでもなかった。それはWinSock向けWindows AFDにおけるCVE-2026-68820である。タロスのリストにあるAI製品の項目はいずれも認可の不具合であり、それこそがこの記録が示すリスクの具体的な形である。

そのどれも、CVE-2026-62830を侵害行為にするものではない。これはすでに修正済みのサービスに関する透明性のためのCVEであり、顧客が何が問題だったのかを確認し、自身の設定を検証できるように公開されたものだ。この記録の価値は、そこに残された設定上の問い、すなわちエージェントのIDが何に到達し得たのか、そしてそれが使われたことに誰かが気づいたかどうか、という点にある。スケジュールすべきパッチではない。