CVE-2026-62825は、Azure Key Vaultの認証処理に関する特権昇格の脆弱性です。CVSS基本値は最大の10.0であるため、脆弱性管理ツールの通知を見て「すぐにパッチを適用しなければならない」と判断した管理者も多いでしょう。
しかし、2026年8月1日時点でMicrosoftは、この脆弱性をサービス側で完全に緩和済みとしており、Azure Key Vault利用者がパッチ適用や設定変更を行う必要はありません。一律のキー交換やシークレットのローテーションも、CVE-2026-62825だけを理由に実施する必要はありません。(Microsoft Security Response Center)
重要なのは、CVSS 10.0という技術的な深刻度と、利用者側の対応要否を分けて判断することです。本記事では、CVE-2026-62825の影響、対応不要とされる理由、Azure管理者が実務上確認しておくべきポイントを整理します。
CVE-2026-62825の結論：利用者側の更新作業は不要
CVE-2026-62825の対応判断を先にまとめると、次のとおりです。
| 確認項目 | 内容 |
|---|---|
| 対象サービス | Azure Key Vault |
| 脆弱性の種類 | 特権昇格 |
| 原因 | 不適切な認証処理 |
| CWE | CWE-287：Improper Authentication |
| CVSS v3.1 | 10.0／Critical |
| 攻撃経路 | ネットワーク経由 |
| 必要な事前権限 | なし |
| ユーザー操作 | 不要 |
| Microsoftの対応 | サービス側で完全に緩和済み |
| 利用者側のパッチ適用 | 不要 |
| Key Vaultの設定変更 | 不要 |
| キーやシークレットの一律交換 | 不要 |
| 実務上の対応 | 脆弱性管理台帳への記録、必要に応じたログ確認 |
公式CVEレコードでは、Azure Key Vaultが影響対象として登録され、クラウド上でのみ提供される「exclusively-hosted-service」として分類されています。利用者がインストールする製品バージョンやKB番号は示されていません。(GitHub)
したがって、Windows Update、Microsoft Update Catalog、Azure CLI、Azure PowerShellなどを使って、利用者が修正プログラムを適用する種類の脆弱性ではありません。
CVE-2026-62825はどのような脆弱性か
CVE-2026-62825は、Azure Key Vaultの認証処理が適切に行われないことにより、権限を持たない攻撃者がネットワーク経由で権限を昇格できる可能性があった脆弱性です。
公式CVEレコードには、次の説明が登録されています。
Azure Key Vaultの不適切な認証により、権限を持たない攻撃者がネットワーク経由で権限を昇格できる。
ただし、具体的にどのAPI、認証トークン、内部コンポーネントに不備があったのかは、公表情報からは確認できません。攻撃用リクエストの形式や再現手順も明らかにされていないため、公開情報だけから具体的な攻撃方法を推測するべきではありません。(GitHub)
CWE-287とは
CVE-2026-62825は、CWE-287「Improper Authentication」に分類されています。
CWE-287は、利用者やシステムが特定の身元を主張した際に、製品がその主張を十分に検証できていない状態を表す分類です。認証の省略、認証結果の誤判定、信頼できない情報による本人確認などが該当する可能性があります。(CWE)
ただし、CWE-287は比較的抽象度の高い分類です。CWE番号だけを見ても、今回の問題がトークン検証、証明書検証、API認証、サービス間認証のどこで発生したのかまでは判断できません。
CVSS 10.0と評価された理由
CVE-2026-62825のCVSS v3.1ベクトルは、次のとおりです。
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:H各指標の意味を整理すると、次のようになります。
| 指標 | 評価 | 意味 |
|---|---|---|
| AV:N | Network | ネットワーク経由で攻撃できる |
| AC:L | Low | 攻撃の複雑性が低い |
| PR:N | None | 攻撃前の権限を必要としない |
| UI:N | None | 利用者の操作を必要としない |
| S:C | Changed | 脆弱なコンポーネントの境界を越えて影響する |
| C:N | None | 機密性への直接的な影響は評価されていない |
| I:H | High | データや処理の完全性に大きな影響がある |
| A:H | High | サービスの可用性に大きな影響がある |
ネットワークから到達でき、事前権限やユーザー操作を必要とせず、完全性と可用性への影響が高いことから、最大値の10.0となっています。(GitHub)
「機密性への影響なし」の意味
CVSSベクトルでは、機密性への影響が「C:N」と評価されています。
これは、今回公表された攻撃シナリオにおいて、Key Vault内のキーやシークレットを直接読み取る影響が評価されていないことを意味します。一方で、次のような意味ではありません。
- すべてのAzureテナントで不審な事象がなかったことの証明
- Key Vaultに関する監視が不要という意味
- キーやシークレットの管理を緩めてよいという意味
- 個別のインシデント調査が不要という意味
CVSSは脆弱性の技術的な影響を表す指標であり、個々の組織で侵害が発生したかどうかを証明するものではありません。
CVSS 10でも利用者対応が不要な理由
CVSS 10.0であるにもかかわらず利用者の対応が不要なのは、CVE-2026-62825がMicrosoftによって運用されるホステッドサービス側の脆弱性だからです。
Azure Key Vaultの基盤、認証処理、サービス内部のソフトウェアは、利用者の仮想マシンや端末上にインストールされているわけではありません。サービス基盤の修正や緩和はMicrosoftが実施します。
今回Microsoftは、脆弱性をすでに完全に緩和し、サービス利用者が行う作業はないと案内しています。(Microsoft Security Response Center)
CVSSは「今すぐ利用者がパッチを当てる必要性」を示す数値ではない
CVSSは、脆弱性が悪用された場合の技術的な深刻度を共通の基準で数値化したものです。
次の要素は、CVSS基本値だけでは判断できません。
- ベンダーによる修正が完了しているか
- 利用者が修正プログラムを適用できる製品か
- クラウド事業者がサービス側で修正する問題か
- 自社環境が実際に攻撃経路へ露出しているか
- 悪用が現実に確認されているか
- 補完的なセキュリティ対策が機能しているか
そのため、脆弱性対応では「CVSSが高いからパッチを探す」のではなく、ベンダーの対応状況と責任分界を確認する必要があります。
| 脆弱性の対象 | 一般的な対応主体 | 利用者の対応例 |
|---|---|---|
| WindowsやWindows Server | 利用者・管理者 | セキュリティ更新を適用 |
| 仮想マシン上のミドルウェア | 利用者・管理者 | パッケージやバージョンを更新 |
| アプリが使用するSDK | 開発者 | 依存ライブラリを更新 |
| Azureのホステッドサービス基盤 | Microsoft | Microsoftがサービス側で修正 |
| CVE-2026-62825 | Microsoft | 利用者側の更新作業なし |
Azure Key Vault利用者が実務上行うべきこと
利用者側の修正作業は不要ですが、組織の脆弱性管理として何も記録しなくてよいわけではありません。
脆弱性管理台帳を「ベンダー緩和済み」に更新する
脆弱性管理ツールや外部監査からCVE-2026-62825を指摘された場合は、次のように記録します。
| 管理項目 | 記録例 |
|---|---|
| 脆弱性ID | CVE-2026-62825 |
| 対象 | Azure Key Vault |
| 深刻度 | Critical／CVSS 10.0 |
| 対応状況 | Microsoftにより完全に緩和済み |
| 利用者対応 | 不要 |
| 対応区分 | Vendor mitigated／Cloud provider remediated |
| 証跡 | MSRCのCVE-2026-62825アドバイザリ |
| 再確認条件 | MSRCの情報更新、Microsoftからの個別通知 |
「誤検知」や「対象外」として処理するよりも、対象サービスは利用しているが、クラウド事業者側で緩和済みと記録する方が正確です。
監査時にも、単にチケットを閉じるのではなく、Microsoftの案内を判断根拠として添付しておくと説明しやすくなります。
Key Vaultの一覧を確認する
大規模なAzure環境では、どのサブスクリプションでKey Vaultを使用しているか把握できていないことがあります。
Azure CLIでは、現在選択しているサブスクリプション内のKey Vaultを次のコマンドで確認できます。
az keyvault list --query "[].{Name:name,ResourceGroup:resourceGroup,Location:location}" -o table複数のサブスクリプションがある場合は、対象を切り替えながら確認します。
az account list -o table
az account set --subscription "<サブスクリプションID>"この確認は修正作業ではなく、脆弱性管理台帳に対象資産を記録するための作業です。
診断設定が有効か確認する
CVE-2026-62825への必須対応ではありませんが、Key Vaultの監視体制を確認する機会として、診断設定を見直すことは有効です。
Key Vaultの監査ログでは、いつ、誰が、どのKey Vaultへアクセスしたかを確認できます。キー、シークレット、証明書の操作や認証APIへの要求も監視対象になります。(Microsoft Learn)
Azure CLIでは、次のコマンドで診断設定を確認できます。
az monitor diagnostic-settings list \
--resource "<Key VaultのリソースID>" \
-o table診断設定がない場合は、Azureポータルで次の順に確認します。
- 対象のKey Vaultを開く
- 「監視」を開く
- 「診断設定」を選択する
- 「診断設定を追加する」を選択する
- Audit LogsまたはAuditEventを有効にする
- Log Analyticsワークスペースなどの送信先を指定する
Azureのリソースログは、診断設定を作成して送信先を指定する必要があります。(Microsoft Learn)
Log Analyticsでアクセス状況を確認する
リソース固有テーブルを使用している環境では、次のKQLで最近の操作、接続元IPアドレス、実行結果を集計できます。
AZKVAuditLogs
| where TimeGenerated > ago(14d)
| summarize Requests = count()
by OperationName, CallerIpAddress, ResultType
| order by Requests descAZKVAuditLogsには、リクエスト元IPアドレスを表すCallerIpAddress、操作名を表すOperationName、処理結果を表すResultTypeなどが記録されます。(Microsoft Learn)
従来のAzureDiagnosticsテーブルへ送信している環境では、次のように確認できます。
AzureDiagnostics
| where TimeGenerated > ago(14d)
| where ResourceProvider == "MICROSOFT.KEYVAULT"
| summarize Requests = count()
by OperationName, CallerIPAddress
| order by Requests desc特に確認したいのは、次のような事象です。
- 見覚えのない接続元IPアドレス
- 使用していないサービスプリンシパルからのアクセス
- 通常発生しない時間帯の大量操作
- キーやシークレットの削除操作
- 予期していない署名、復号、取得処理
- 短時間に集中した認証エラー
- 運用手順にないKey Vault設定の変更
ただし、このログ確認はMicrosoftが要求するCVEの修正手順ではありません。通常のセキュリティ監視や、組織独自のリスク判断として実施するものです。
キーやシークレットのローテーションは必要か
CVE-2026-62825だけを理由に、Key Vault内のキー、シークレット、証明書を一律にローテーションする必要はありません。
不要なローテーションを行うと、次の問題が発生する可能性があります。
- アプリケーションが古いシークレットを参照して停止する
- 証明書更新が反映されず通信障害が発生する
- 暗号化キーのバージョン不整合が起きる
- CI/CDパイプラインや外部サービスとの連携が失敗する
- 障害原因とセキュリティ対応の切り分けが難しくなる
一方、次のいずれかに該当する場合は、CVE対応とは別にインシデント対応を開始し、影響を受けた資格情報のローテーションを検討します。
- Microsoftからテナント固有のセキュリティ通知を受けた
- Key Vaultログに不審な操作が記録されている
- 未知のIDやIPアドレスによるアクセスが確認された
- キーやシークレットが意図せず取得・変更・削除された
- 関連するサービスプリンシパルやユーザーが侵害された
- Microsoft SentinelやDefender for Cloudから関連アラートが出ている
この場合も、すべてのキーを無条件に交換するのではなく、影響を受けたID、操作、Key Vault、オブジェクトを特定してから対応範囲を決めます。
Azure SDKやクライアントライブラリの更新は必要か
CVE-2026-62825について、利用者が使用するAzure SDKやKey Vaultクライアントライブラリの更新は案内されていません。
公式CVEレコードで対象として示されているのはAzure Key Vaultのホステッドサービスです。特定のNuGet、npm、Maven、Pythonパッケージなどは対象製品として登録されていません。(GitHub)
そのため、次のような対応をCVE-2026-62825の修正として行う必要はありません。
Azure.Security.KeyVault.Secretsの緊急更新@azure/keyvault-secretsの緊急更新- Python版Azure SDKの緊急更新
- Java版Key Vault SDKの緊急更新
- Azure CLIやAz PowerShellモジュールの緊急更新
もちろん、SDKをサポート対象の最新版に保つこと自体は重要です。ただし、それは通常の依存関係管理であり、CVE-2026-62825への直接的な修正作業ではありません。
脆弱性スキャナーが「未対応」と表示する場合の判断
一部の脆弱性管理製品は、CVSS 10.0という情報だけを取得し、対応状態を「Critical」「Open」「要修正」などと表示することがあります。
しかし、Azure Key Vaultのサービス基盤は利用者がスキャンしたり、パッチを適用したりできる資産ではありません。
次のように対応します。
- 検出対象がAzure Key Vaultであることを確認する
- CVE番号がCVE-2026-62825であることを確認する
- MSRCで「完全に緩和済み」「利用者の作業なし」であることを確認する
- チケットへMSRCの案内を証跡として登録する
- ステータスを「ベンダー緩和済み」などへ変更する
- 誤ってWindowsやSDKのパッチを探していないか確認する
スキャナー上で例外登録する場合も、恒久的な除外ではなく、CVE番号、対象サービス、ベンダー対応状況を明記した期限付きまたは根拠付きの例外として管理すると安全です。
よくある誤解と正しい判断
| 誤解 | 正しい判断 |
|---|---|
| CVSS 10なら必ず緊急パッチが必要 | CVSSと利用者の対応要否は別に判断する |
| 対応不要なら脆弱性台帳に記録しなくてよい | ベンダー緩和済みとして判断根拠を残す |
| Key Vaultの全シークレットを交換すべき | 不審な事象がなければ一律交換は不要 |
| Azure SDKを更新すれば修正できる | 今回はホステッドサービス側の問題 |
| C:Nなので確認作業は一切不要 | C:NはCVSS上の直接的な機密性影響の評価 |
| スキャナーのCritical表示をそのまま信じる | MSRCの最新ステータスと責任分界を確認する |
管理者向けの対応判断フロー
CVE-2026-62825への対応は、次の基準で判断できます。
Azure Key Vaultを利用していない場合
直接の影響対象ではありません。
脆弱性管理台帳には「対象サービス未使用」または「該当資産なし」と記録します。
Azure Key Vaultを利用しており、不審な事象がない場合
利用者側のパッチ適用、設定変更、キー交換は不要です。
「Microsoftによりサービス側で完全に緩和済み」と記録し、通常の監視を継続します。
Azure Key Vaultを利用しており、不審なログがある場合
CVE-2026-62825の修正作業ではなく、通常のインシデント対応として調査します。
影響を受けたID、接続元、操作、キー、シークレットを特定し、必要に応じてアクセス無効化、権限削除、資格情報のローテーションを行います。
Microsoftから個別通知を受けた場合
一般公開されている「対応不要」という情報よりも、Microsoftから届いたテナント固有の案内を優先します。
Azure Service Health、Microsoft Defender for Cloud、登録済みの管理者メールアドレスなどに届いた通知を確認し、案内された手順に従います。
CVE-2026-62825への最終的な対応
CVE-2026-62825は、Azure Key Vaultの不適切な認証処理によって、事前権限を持たない攻撃者がネットワーク経由で権限を昇格できる可能性があった、CVSS 10.0の脆弱性です。
技術的な深刻度は最大ですが、MicrosoftはAzure Key Vaultのサービス側で完全に緩和済みとしており、利用者が行うパッチ適用や設定変更はありません。
Azure管理者が次に行うべきことは、緊急のキー交換ではなく、次の3点です。
- 脆弱性管理台帳を「Microsoftによる緩和済み」に更新する
- MSRCのアドバイザリを対応根拠として保存する
- Key Vaultの診断設定と通常の監視体制を確認する
CVSSの数値だけで対応を決めず、対象が利用者管理のソフトウェアなのか、クラウド事業者が管理するサービスなのかを確認することが、CVE-2026-62825を正しく処理するための重要なポイントです。
コメント