マイクロソフトのAI操作エージェントのマルチテナント認証ギャップにより、ライブコマンドストリーム、内部推論、認証情報が任意のEntra IDアカウントに露出していたと研究者は述べています。
マイクロソフトのAzure SREエージェントの高深刻度認証脆弱性により、機密エージェントデータが不正なネットワークアクセスに露出していました。これは確認された脆弱性公開によるものです。
この問題はEnclave AI研究者のYanir Tsarimiによって特定されました。彼はブログ投稿でエージェントのインタラクションに適切な認証制御なしでアクセス可能だったことを詳しく説明しています。この脆弱性はCVE-2026-32173として追跡され、CVSSスコア8.6で重大と評価されています。
ブログの中で、Tsarimiはエージェント活動が実行中に観察される可能性があるシナリオ、ユーザーとシステム間のインタラクションを含めて説明しています。この露出はサービスの認証ギャップに起因し、有効な認証情報なしでデータストリームへのアクセスが可能でした。
NVDエントリによれば、マイクロソフトはこれを不適切な認証問題として分類し、不正な攻撃者がネットワーク経由で情報を開示することを可能にするものとしています。
「あなたがすべてにアクセス可能なアシスタント（あなたのサーバ、ログ、パスワード、ソースコード）を雇ったと想像してください。次に、全く関係のない企業の知らない人が、そのアシスタントが持つあらゆる会話を静かに聞くことができたと想像してください」とEnclave研究者のYanir Tsarimiは書きました。「それが私たちがAzure SREエージェントで発見したものです。」
その後、マイクロソフトはこの問題を修正しました。修正はサーバ側で適用され、マイクロソフトのアドバイザリでは顧客による対応は不要であると述べられています。Azure SREエージェントは3月10日に一般提供開始となりました。
デフォルトでマルチテナント
エージェントは/agentHubと呼ばれるWebSocketエンドポイントを通じてすべての活動をストリーミングしていました。
エンドポイントは接続にトークンが必要でしたが、基盤となるEntra IDアプリケーション登録はマルチテナントとして構成されており、任意のEntra IDテナント内のアカウントがハブが受け入れる有効なトークンを取得できることを意味していました。
「ハブはその後チェックしました: トークンは有効ですか? はい。オーディエンスは正しいですか? はい。次のことを尋ねることはありませんでした: 呼び出し元はターゲットのテナントに属していますか? このエージェントの使用が認可されていますか? このリソースについて何か役割がありますか?」とTsarimiは書きました。
接続されると、ハブはすべてのイベントをすべてのクライアントにIDフィルタリングなしで配信していました。
露出したチャネルには、ユーザープロンプト、エージェントの応答、内部推論トレース、完全な引数で実行されたあらゆるコマンド、およびコマンド出力が含まれていました。
「私たち独自のテスト環境では、エージェントが定常的なタスクを実行し、ライブウェブアプリケーションのデプロイメント認証情報を返すのを見ました」とTsarimiは書きました。「実際のターゲットに対する盗聴者は同じものを受け取ったでしょう。静かに。他に誰かが通信している可能性を示すものは何もなく。」
悪用には、Enclaveが予測可能で列挙可能であると説明したターゲットエージェントのサブドメインと、およそ15行のPythonが必要でした。サードパーティトラッカーは影響を受けたコンポーネントをAzure SRE Agent Gateway SignalR Hubとして特定しました。
特権オペレーターの思考プロセスを観察する
このカテゴリの脆弱性は従来のAPIバグと密接に比較すべきではないと、チューリッヒに本拠を置く金融インフラストラクチャ事業者SIX Groupのサイバーセキュリティ研究者兼エグゼクティブディレクターのAlexander Hagenah氏は述べています。
「通常のAPI問題は通常、特定のエンドポイント、データセット、または権限チェックに制限されています。AI操作エージェントの場合、エージェント自体がインフラストラクチャ状態、ログ、ソースコード、インシデントコンテキスト、コマンド、出力、およびトラブルシューティング中に現れる認証情報の集約ポイントになります」とHagenah氏は述べました。
「実際には、特権オペレーターが声に出して考えているのを見ているのと同じように見えます」と彼は付け加えました。
この露出は自動的なインフラストラクチャ侵害につながるものではないとHagenah氏は述べていますが、多くのリードオンリーバグよりも価値があります。攻撃者は通常、初期アクセス後に環境を理解するために懸命に働く必要があります。SREエージェントはすでにそのコンテキストがアセンブルされているかもしれません。
この接続はまた被害者側に痕跡を残さなかったと研究者は書きました。「被害者組織はそれを検出する方法がなく、その後調査する方法がなく、何が露出していたかを範囲を定める方法がありませんでした。」
企業向けの考慮事項
ブログ投稿に従って、Enclaveはプレビューウィンドウ中にAzure SREエージェントを実行した組織は、その期間を潜在的に露出していると見なし、エージェント会話またはCLI出力を通じて渡された可能性のある認証情報、構成データ、または機密情報をレビューする必要があると指摘しました。
Hagenah氏は、エージェント操作サービスは通常のSaaSツールではなく、特権自動化プラットフォームのようにより多く管理される必要があると述べています。
「そのレベルのアクセスを許可する前に、テナント分離とリソースレベルの認可について非常に明確な回答が欲しいです。トークンが有効であるだけでは十分ではありません。サービスは、呼び出し元が正しいテナントに属していること、特定のエージェントについて認可されていること、その特定のストリーム、スレッド、ツール出力、またはアクションにアクセスできることを確認する必要があります」と彼は述べました。
エージェントは最小限の権限を持つ専用の管理ID下で実行される必要があり、コマンド実行、ログクエリ、ソースリポジトリ、インシデントプラットフォームとの統合は他の特権システムと同様にレビューされるべきとHagenah氏は述べています。企業はまた、誰が接続したか、どのスレッドにアクセスしたか、どのコマンドが実行されたか、どのような出力が返されたかを知る必要があり、ログはSIEMにエクスポート可能である必要があります。マイクロソフトはコメント依頼にすぐに応じませんでした。
