CVE-2026-56167とは？Azure AI SearchのSSRFは緩和済み・対応不要

Azure AI SearchでCVE-2026-56167が公表され、「CVSS 8.5ならすぐにパッチを当てる必要があるのでは」と不安になった管理者も多いでしょう。

結論から言うと、CVE-2026-56167についてAzure AI Search利用者が更新プログラムの適用や設定変更を行う必要はありません。Microsoftは脆弱性をサービス側で完全に緩和済みとしており、利用者側の対応は不要です。

ただし、「対応不要」は「確認も記録も不要」という意味ではありません。脆弱性管理台帳には、Azure AI Searchの利用有無、Microsoft側で緩和済みであること、顧客作業が不要であることを記録しておくのが実務上の適切な対応です。

CVE-2026-56167はAzure AI Search側で緩和済み

CVE-2026-56167は、Azure AI Searchに存在したサーバーサイドリクエストフォージェリ、いわゆるSSRFの脆弱性です。一定の権限を持つ攻撃者がネットワーク経由で悪用し、本来与えられている範囲を超えて権限を昇格できる可能性がありました。

概要は次のとおりです。

項目	内容
CVE番号	CVE-2026-56167
対象サービス	Azure AI Search
脆弱性の種類	サーバーサイドリクエストフォージェリ（SSRF）
影響	特権昇格
CWE	CWE-918
MicrosoftのCVSS	8.5（High）
攻撃元	ネットワーク
必要な権限	低い権限が必要
利用者の操作	不要
Microsoftの対応	サービス側で完全に緩和済み
Azure利用者の作業	不要

CVEレコードには、Microsoftがクラウドサービスの脆弱性に使用するexclusively-hosted-serviceタグが付けられています。Microsoftは、このタグを「顧客側の作業が不要な脆弱性」を示すものとして運用しています。Security Update Guideでも、CVE-2026-56167はMicrosoft側で緩和済みであり、サービス利用者が行う作業はないとされています。(Microsoft Security Response Center)

「対応不要」の正しい意味

今回の対応不要という判断は、脆弱性が軽微だからではありません。

Azure AI SearchはMicrosoftが基盤を管理するクラウドサービスです。そのため、サービス内部の修正はMicrosoftが実施し、利用者がサーバーへパッチをインストールする必要はありません。

したがって、次のように理解するのが適切です。

脆弱性が存在した時点での潜在的な影響は大きい
Microsoftは問題をサービス側で修正・緩和した
現在の利用者環境に適用する更新プログラムはない
設定変更、再起動、再デプロイも求められていない
CVEは脆弱性情報の透明性を高める目的で公表されている

Microsoftは2024年以降、顧客によるパッチ適用が不要な場合でも、重大なクラウドサービスの脆弱性にCVE番号を割り当てて公表する方針を明確にしています。つまり、クラウドサービスのCVEは必ずしも「利用者が今すぐ修正する必要がある通知」とは限りません。(Aka.ms)

CVE-2026-56167のSSRFとは

SSRFは、外部から与えられたURLや接続先をサーバーが十分に検証せず、想定外の宛先へリクエストを送信してしまう脆弱性です。

通常、攻撃者の端末からは直接アクセスできない内部APIや管理用サービスでも、クラウドサービスのサーバーからはアクセスできる場合があります。攻撃者がサーバーを代理アクセスのように利用できると、ネットワーク境界やアクセス制御を回避される可能性があります。

MITREのCWE-918でも、SSRFは「サーバーが受け取ったURLなどを基にコンテンツを取得する際、要求が想定した宛先へ送信されることを十分に確認していない問題」と定義されています。また、サーバーを経由させることで、攻撃者から直接は到達できない宛先へのアクセス制御を回避できる可能性が示されています。(CWE)

SSRFが特権昇格につながる理由

SSRFそのものは「不正な外部通信を発生させる脆弱性」ですが、サーバーが持つネットワーク上の到達性やサービス権限を利用できると、特権昇格につながります。

考え方としては、次のような流れです。

攻撃者がAzure AI Searchの特定機能へ不正な入力を与える
Azure AI Search側のサーバーが、攻撃者の指定した宛先へリクエストを送る
リクエストがAzure AI Searchのサービス側コンテキストで実行される
攻撃者自身の権限では到達できない情報や操作へアクセスできる
結果として、当初の権限を超えたアクセスにつながる

ただし、Microsoftが公開している説明では、悪用対象となった具体的なAPI、パラメーター、内部接続先、必要なAzureロールまでは明らかにされていません。

そのため、「Search Service Contributorを持っていれば必ず悪用できる」「特定のインデクサーを使っていると影響を受ける」といった具体的な条件を、公開情報だけから断定することはできません。

CVSS 8.5の内容を読み解く

Microsoftが付与したCVSS v3.1のベーススコアは8.5で、深刻度はHighです。

ベクターは次のとおりです。

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N

指標	評価	意味
AV:N	Network	ネットワーク経由で攻撃可能
AC:L	Low	攻撃条件の複雑さが低い
PR:L	Low	低い権限が事前に必要
UI:N	None	別の利用者による操作は不要
S:C	Changed	影響が別のセキュリティ境界へ及ぶ
C:H	High	機密性への影響が大きい
I:L	Low	完全性への影響は限定的
A:N	None	可用性への直接的な影響はない

特に注意したいのは、PR:Lです。

CVEの説明は「権限を持つ攻撃者」が悪用できるとしています。インターネット上の誰でも認証なしで攻撃できる脆弱性としては評価されていません。

一方で、AC:LとUI:Nであるため、必要な権限を持つアカウントやサービスプリンシパルが侵害された場合には、追加の利用者操作を必要とせず悪用できた可能性があります。(NVD)

CVSSが高くても緊急作業が不要な理由

CVSSは、主に「脆弱性が未修正の状態で悪用された場合、どの程度大きな影響があるか」を示す指標です。

次の要素は、CVSSの数値だけでは判断できません。

すでにベンダーが修正しているか
利用者側に適用すべきパッチがあるか
現在も攻撃可能な状態か
実際に悪用が確認されているか
修正の責任がクラウド事業者と利用者のどちらにあるか

そのため、脆弱性対応ではCVSSだけを見て作業を決めるのではなく、次の順番で確認する必要があります。

自組織が対象サービスを利用しているか
ベンダーが顧客対応を求めているか
修正方法や回避策が提供されているか
悪用の有無や公開状況はどうなっているか
自組織の権限構成やデータの重要度はどうか

CVE-2026-56167はスコアこそ8.5ですが、Microsoft側の緩和が完了しているため、利用者の緊急作業にはつながりません。

CVSS 8.5と8.8の表記が混在する理由

CVE-2026-56167を検索すると、サイトによって「8.5」と「8.8」が表示される場合があります。

これは誤植ではなく、MicrosoftとNISTが異なる評価を付けているためです。

評価元	CVSS	主な違い
Microsoft Corporation CNA	8.5	スコープ変更、機密性High、完全性Low、可用性None
NIST NVD	8.8	スコープ変更なし、機密性・完全性・可用性がHigh

NVDはMicrosoftのCNAスコア8.5と、NIST独自評価の8.8を併記しています。JVN iPediaではNVD値を採用しているため、8.8と表示されています。(NVD)

Microsoft製品の対応要否を判断する際は、まずベンダーでありCNAでもあるMicrosoftの評価とSecurity Update Guideを確認します。

ただし、8.5と8.8のどちらも深刻度はHighです。今回の実務判断を左右するのは0.3ポイントの差ではなく、Microsoft側で緩和済みかどうかです。

自組織が影響を受けるか判断する方法

対応要否は、次の表で判断できます。

自組織の状況	判定	実施すること
Azure AI Searchを利用していない	非該当	資産台帳に非該当の根拠を記録
Azure AI Searchを利用している	該当・ベンダー緩和済み	顧客作業不要として記録
利用状況が分からない	要確認	Azureリソースを棚卸し
不審な設定変更や認証情報の利用がある	別途調査	CVE対応ではなくインシデントとして調査
Microsoftから個別通知を受けている	要確認	通知内容を優先して対応

Azure Resource GraphでAzure AI Searchを確認する

複数のサブスクリプションを管理している場合は、Azure PortalのResource Graph Explorerで次のクエリを実行すると、Azure AI Searchリソースを一覧化できます。

Resources
| where type =~ "microsoft.search/searchservices"
| project
    name,
    resourceGroup,
    subscriptionId,
    location,
    sku = tostring(sku.name)
| order by subscriptionId asc, resourceGroup asc, name asc

検索結果が0件なら、選択したサブスクリプションの範囲ではAzure AI Searchリソースが見つかっていません。

結果が表示された場合でも、CVE-2026-56167に対するパッチ適用は不要です。リソース名、管理部門、システム用途を確認し、脆弱性管理台帳へ記録します。

管理者が実施すべき作業

CVE-2026-56167について、管理者が行うべき作業を整理すると次のようになります。

作業	必要性	判断
Windows UpdateやKBの適用	不要	Azure AI Searchのクラウドサービス側で修正
Azure AI Searchの再起動	不要	Microsoftから指示なし
サービスの再デプロイ	不要	Microsoftから指示なし
インデックスの再作成	不要	脆弱性対策にはならない
インデクサーの再実行	不要	脆弱性対策にはならない
Azure SDKの更新	不要	本CVEに対するクライアントSDK更新は示されていない
APIキーの緊急ローテーション	原則不要	本CVEのみを理由とした指示はない
Azure RBACの棚卸し	推奨	通常の防御強化として有効
ログ設定の確認	推奨	今後の調査や監査に有効
脆弱性管理台帳への記録	必要	対応不要と判断した根拠を残す
MSRC情報の継続監視	推奨	アドバイザリ更新に備える

脆弱性管理台帳の記載例

社内の脆弱性管理システムやチケットには、次のように記録できます。

対象CVE：CVE-2026-56167
対象製品：Azure AI Search
利用状況：利用あり／利用なし
判定：Microsoft側で完全に緩和済み
顧客対応：不要
パッチ適用：対象外
設定変更：不要
補足：Microsoft Security Update GuideおよびクラウドCVEのcustomer action判定を確認
継続対応：MSRCの更新情報を監視

「対応不要」のみを記録するのではなく、判断日と参照したMicrosoft情報も残しておくと、後日の監査や上司への説明が容易になります。

対応不要でも確認したい防御強化

以下の設定はCVE-2026-56167を修正するための作業ではありません。

ただし、同様のクラウド権限悪用やアカウント侵害の影響を抑えるため、通常のセキュリティ点検として実施する価値があります。

Azure RBACを最小権限にする

Azure AI Searchでは、Microsoft Entra IDを利用したロールベースのアクセス制御を使用できます。Microsoftはロールベースのアクセスを推奨しており、必要に応じて管理プレーンとデータプレーンの権限を分離できます。

代表的なロールは次のとおりです。

ロール	主な用途
Reader	サービス設定やメトリックの参照
Search Service Contributor	インデックス、インデクサー、スキルセットなどの管理
Search Index Data Contributor	ドキュメントの登録、更新、検索
Search Index Data Reader	インデックスの検索、読み取り

Owner、Contributor、Search Service Contributorなどの強いロールは、管理キーの取得を含む広い権限を持つ場合があります。個人アカウントへ恒常的に付与せず、必要な作業と期間に限定することが重要です。(Microsoft Learn)

確認時には、Azure AI Searchリソースの「アクセス制御（IAM）」で次の項目を点検します。

退職者や異動者のロールが残っていないか
不要なOwnerやContributorが存在しないか
サービスプリンシパルに過剰な権限がないか
サブスクリプションやリソースグループから強い権限を継承していないか
読み取りだけのアプリに書き込み権限を付与していないか

なお、CVE-2026-56167を悪用できた具体的なロールは公開されていません。特定のロールを削除すれば本CVEへの対応になる、という意味ではありません。

不要なパブリックアクセスを制限する

Azure AI SearchはPrivate Endpointに対応しています。Private Endpointを利用すると、仮想ネットワークからプライベート接続でAzure AI Searchへアクセスし、パブリックエンドポイントを無効化できます。

Microsoftのドキュメントでは、Private Endpointによって通信をMicrosoftのバックボーン上に限定し、パブリックインターネットへの露出をなくせると説明されています。(Microsoft Learn)

ただし、Private Endpointの設定はCVE-2026-56167に対する必須の緩和策ではありません。次の条件に該当する環境で、通常のネットワーク防御として検討します。

社内システムからのみAzure AI Searchを利用する
インターネット公開が不要
機密性の高い文書をインデックス化している
Azure OpenAIやRAGシステムのバックエンドとして利用している
セキュリティ基準でPaaSのパブリックアクセスを禁止している

Azure Monitorと診断設定を確認する

Azure AI SearchはAzure Monitorでメトリック、リソースログ、アクティビティログを監視できます。

プラットフォームメトリックは自動的に収集されますが、リソースログは診断設定を作成し、Log Analytics、ストレージアカウント、Event Hubsなどへ転送しなければ保存・検索できません。(Microsoft Learn)

少なくとも次の状態を確認しておくと、将来のインシデント調査に役立ちます。

診断設定が有効になっている
必要なログカテゴリがLog Analyticsへ送信されている
Azure Activity Logを監視できる
管理キーの取得や設定変更を追跡できる
ログの保持期間が組織の基準を満たしている
重要な設定変更にアラートを設定している

Azure AI Searchのアクティビティログでは、サービスの作成や構成変更などのコントロールプレーン操作に加え、管理APIキーが使用されたことを示す記録も確認できます。ただし、APIキーを使って実行された個別処理の詳細まですべて記録されるわけではありません。(Microsoft Learn)

APIキーやシークレットのローテーションは必要か

CVE-2026-56167だけを理由に、Azure AI Searchの管理キー、クエリキー、接続先ストレージのシークレットを緊急ローテーションする必要はありません。

Microsoftは利用者側の作業を求めておらず、資格情報の漏えいを前提としたローテーション指示も出していません。

ただし、次のような別の兆候がある場合は、CVE対応とは切り分けてインシデント対応を行います。

身に覚えのない管理キー取得履歴がある
不審なロール割り当てが追加されている
未承認のインデックスやインデクサーが作成されている
通常とは異なるサービスプリンシパルが操作している
接続先データソースで不審なアクセスが発生している
Microsoftからテナント固有の通知を受け取った

この場合は、ログを保全したうえで、関係するキーやシークレットのローテーション、アカウントの無効化、Microsoftサポートへの問い合わせを検討します。

2026年8月1日時点で悪用は確認されているか

2026年8月1日時点で確認できる公開情報では、CISAのSSVC情報はCVE-2026-56167の悪用状況をnoneと評価しています。

これは「世界中で一度も悪用されなかった」と証明するものではありませんが、少なくとも公開情報上、進行中の大規模な悪用を示す情報は確認されていません。(NVD)

Microsoft側の緩和が完了していることも踏まえると、現時点で利用者がサービスを停止したり、インデックスを削除したりする必要はありません。

CVE-2026-56167に関するよくある疑問

Azure AI Searchを利用しているだけで侵害された可能性がありますか

Azure AI Searchを利用しているという事実だけでは、侵害されたとは判断できません。

CVEの説明では、悪用には一定の権限が必要とされています。また、Microsoftはサービス側の緩和を完了しています。不審な操作やMicrosoftからの個別通知がない限り、本CVEだけを理由に侵害を前提とした調査を開始する必要はありません。

Azure AI SearchのSKUやリージョンによって対応は変わりますか

公開情報では、特定のSKU、リージョン、APIバージョンに限定した顧客対応は示されていません。

Microsoftがサービス側で緩和しているため、Standard、BasicなどのSKUごとに利用者が異なる更新作業を行う必要はありません。

Azure SDKやREST APIのバージョンを上げる必要はありますか

本CVEについて、Azure AI Search SDKやREST APIの特定バージョンへ更新するよう求める案内はありません。

今回の問題はMicrosoftが管理するAzure AI Searchサービス側の脆弱性として扱われています。アプリケーションの依存パッケージ更新とは分けて判断してください。

インデックスを作り直した方が安全ですか

インデックスの削除や再作成は、CVE-2026-56167の修正にはなりません。

インデックス、インデクサー、スキルセットの再作成はサービス停止や検索品質への影響を伴うため、根拠なく実施しないようにしてください。

CVSS 8.5なら社内基準上は緊急対応ではありませんか

社内基準がCVSSだけで自動的に期限を決めている場合でも、「ベンダー側で修正済み」「顧客作業なし」という例外を適用できるか確認してください。

チケット自体を削除するのではなく、次のようにクローズするのが適切です。

対象サービス利用あり
CVSS 8.5
Microsoft側で緩和済み
customer action不要
顧客側パッチなし
ベンダー対応完了としてクローズ

CVE-2026-56167への対応を整理

CVE-2026-56167は、Azure AI Searchに存在したSSRFによる特権昇格の脆弱性です。MicrosoftのCVSSは8.5で、未修正状態を前提とすれば影響の大きい問題でした。

一方、Microsoftはクラウドサービス側で完全に緩和しており、Azure AI Search利用者がパッチ適用、設定変更、再起動、インデックス再作成、APIキーの緊急ローテーションを行う必要はありません。

管理者が行うべきなのは、次の3点です。

Azure AI Searchの利用有無を確認する
「該当するがMicrosoft側で緩和済み、顧客作業なし」と記録する
RBAC、Private Endpoint、診断ログを通常のセキュリティ対策として点検する

CVE-2026-56167は対策不要ですが、確認結果と判断根拠は残しておく。これが、過剰対応を避けながら監査にも耐えられる実務的な対応です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

CVE-2026-56167とは？Azure AI SearchのSSRFは緩和済み・対応不要