CVE-2026-62835:Azure Portalの情報漏えいは緩和済み、対応不要

CVE-2026-62835について、Azure利用者がパッチ適用や設定変更を行う必要はありません。MicrosoftはAzure Portal側で問題を完全に緩和済みとしており、顧客側の作業は不要です。端末への更新プログラム適用、Azureリソースの再構築、Azure Portalの無効化などを行う必要もありません。(Microsoft Security Response Center)

ただし、CVSS基本値は9.3で、ネットワーク経由かつ事前の権限を必要としない情報漏えい脆弱性です。「対応不要だから記録もしなくてよい」という意味ではありません。脆弱性管理台帳には、Microsoft側で緩和済みのクラウドサービス脆弱性として記録し、公式情報の更新や個別通知を確認するのが実務的な対応です。

目次

CVE-2026-62835の概要

CVE-2026-62835は、Azure Portalの認可処理が正しく行われないことにより、本来アクセスを許可されていない攻撃者がネットワーク経由で情報を取得できる可能性があった脆弱性です。

項目内容
CVE IDCVE-2026-62835
対象サービスAzure Portal
脆弱性の種類情報漏えい
原因不適切な認可処理
CWECWE-285:Improper Authorization
MicrosoftのCVSS基本値9.3、Critical
攻撃経路ネットワーク
攻撃の複雑さ低い
必要な権限なし
ユーザー操作不要
対策状況Microsoft側で完全に緩和済み
利用者側の対応不要

MicrosoftがCNAとして登録したCVEレコードでは、Azure Portalが対象製品として指定され、CWE-285、CVSS 9.3、ネットワーク経由、権限不要、ユーザー操作不要という評価になっています。また、利用者が更新する製品ではなく、Microsoftが管理する「exclusively-hosted-service」として登録されています。

Azure Portalで何が起きる脆弱性だったのか

Azure Portalは、仮想マシン、ストレージ、ネットワーク、データベース、課金情報などのAzureリソースをWebブラウザから管理するための統合コンソールです。Azure利用者の端末にインストールする管理ソフトではなく、Microsoftがクラウド上で提供、運用しています。(Microsoft Learn)

CVE-2026-62835では、このAzure Portal内の認可処理に問題がありました。

認証と認可は意味が異なる

認証と認可は混同されやすい用語ですが、役割が異なります。

用語確認する内容具体例
認証利用者が誰であるかID、パスワード、MFAによる本人確認
認可その利用者に何が許可されているか仮想マシンの閲覧、設定変更、削除の許可

CWE-285は、リソースへのアクセスや操作を要求された際に、システムが認可チェックを実行しない、または正しく実行しない問題を示します。(CWE)

たとえば、利用者Aには自社テナント内の情報だけを表示すべきところ、認可チェックが正しく機能しなければ、本来表示してはいけない情報が応答に含まれる可能性があります。

ただし、これはCWE-285を説明するための一般的な例です。CVE-2026-62835について、Microsoftは対象となった具体的な画面、API、情報の種類、影響を受けたテナントの範囲を公開情報で明らかにしていません。

そのため、次のような情報が実際に漏えいしたと断定することはできません。

  • Azureアカウントのパスワード
  • アクセストークン
  • ストレージアカウントのキー
  • Key Vault内のシークレット
  • 仮想マシン内のファイル
  • 顧客データや個人情報
  • 他テナントのリソース情報

公式のCVEレコードから確認できるのは、「不適切な認可によって、権限のない攻撃者がネットワーク経由で情報を開示させられる可能性があった」という範囲です。

CVSS 9.3と評価された理由

MicrosoftのCVSS v3.1評価は、次のベクトルです。

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

指標評価実務上の意味
AVNetworkネットワーク経由で攻撃できる
ACLow特殊で複雑な攻撃条件を必要としない
PRNone攻撃前にAzure上の権限を取得する必要がない
UINone管理者や利用者にリンクを開かせる操作などが不要
SChanged影響が脆弱な処理のセキュリティ範囲を越える可能性がある
CHigh機密性への影響が大きい
INone情報や設定の改ざんは評価されていない
ALow可用性への影響は限定的と評価されている

ネットワーク経由で到達でき、攻撃の複雑さが低く、既存の権限もユーザー操作も必要としないため、技術的な深刻度は高く評価されています。特に、機密性への影響が「High」であることが、9.3という高いスコアにつながっています。

CVSS v3.1では、9.0から10.0がCriticalに分類されます。ただし、CVSS基本値は脆弱性そのものの技術的な深刻度を表すものであり、「利用者が直ちにパッチを適用しなければならないか」を直接示す数値ではありません。(FIRST)

CVSS 9.3でも利用者の対応が不要な理由

CVE-2026-62835で利用者側の対応が不要なのは、Azure PortalがMicrosoftによって管理されるクラウドサービスだからです。

Windows Serverやオンプレミス製品の脆弱性であれば、利用者が更新プログラムを入手し、検証環境で確認したうえで本番環境に適用する必要があります。一方、Azure Portalのプログラムや基盤はMicrosoftが管理しているため、利用者はPortal自体のバージョンを選択したり、修正プログラムをインストールしたりできません。

比較項目オンプレミス製品Azure Portal
ソフトウェアの管理者利用企業Microsoft
更新の適用者利用企業Microsoft
利用者がバージョンを選べるか製品によって可能基本的に不可
修正プログラムの検証利用企業が実施Microsoftがサービス側で実施
CVE-2026-62835への対応該当しないMicrosoft側で緩和済み

今回の「利用者の対応は不要」という案内は、脆弱性が軽微だったという意味ではありません。問題の修正主体が利用企業ではなくMicrosoftであり、必要な対策がすでにサービス側で完了しているという意味です。(Microsoft Security Response Center)

利用者側で実施しなくてよい作業

CVE-2026-62835だけを理由として、次の作業を行う必要はありません。

  • Windowsやブラウザへの緊急更新プログラム適用
  • Azure Portalの設定変更
  • Azureサブスクリプションの再作成
  • 仮想マシンやストレージの再構築
  • Azure Portalへのアクセス停止
  • Azure CLIやAzure PowerShellへの切り替え
  • 全利用者のパスワード一斉変更
  • サービスプリンシパルのシークレット一斉更新
  • Key Vault内のシークレット一斉ローテーション
  • Azure RBACロールの緊急削除
  • 利用中のAzureリソースの停止

特に、根拠のないパスワード変更やシークレットの一斉ローテーションは、アプリケーション停止や認証エラーを引き起こす可能性があります。

Microsoftからテナント固有の通知が届いた場合や、不審なアクセスを示す別の証拠がある場合は個別対応が必要ですが、CVE-2026-62835の公開情報だけを理由に実施する作業ではありません。

Azure管理者が実務上行うべきこと

技術的な修正作業は不要ですが、企業や組織のAzure管理者は、次のように処理すると脆弱性管理や監査で説明しやすくなります。

優先度実施内容判断
必須パッチや設定変更不要
推奨脆弱性管理台帳への記録実施する
推奨Microsoft公式情報の保存実施する
推奨対応ステータスを「ベンダー側で緩和済み」に変更実施する
推奨Microsoftからの個別通知の有無を確認実施する
条件付きAzureログの確認高リスク環境や個別通知がある場合
条件付きインシデント調査不審な事象がある場合
不要全利用者への緊急作業依頼実施しない

脆弱性管理台帳には対応不要の根拠を残す

単に「対応不要」と記載するだけでは、後日、監査担当者や管理職から理由を確認されたときに説明できません。

次のように記録すると明確です。

CVE-2026-62835はMicrosoft管理下のAzure Portalに存在した認可不備。Microsoftがサービス側で完全に緩和済みとしており、顧客側のパッチ適用および設定変更は不要。MSRCの更新情報を継続確認する。

管理台帳には、少なくとも次の情報を残します。

  • CVE番号
  • 対象サービス
  • CVSS
  • 脆弱性の概要
  • 利用者側の対応要否
  • 対応不要と判断した根拠
  • 公式情報を確認した日
  • 再確認の要否
  • 担当者または承認者

「Criticalだから未対応」とするのではなく、「Criticalだが、クラウドサービス側で緩和済み」と区別することが重要です。

Microsoftからの個別通知を確認する

MSRCの一般公開情報とは別に、影響を受けた可能性のある顧客へ、Azure Service Health、Azure Portal、登録メールアドレスなどを通じて個別の案内が行われる場合があります。

個別通知が届いている場合は、一般的な「対応不要」という説明よりも、通知に記載された内容を優先してください。通知内でログ調査、認証情報の変更、Microsoftサポートへの連絡などが求められていれば、その指示に従います。

ログ調査は必要か

Microsoftが利用者側の作業を不要としているため、すべての組織がCVE-2026-62835専用のログ調査を行う必要はありません。

ただし、次のような環境では、通常のセキュリティ確認の一環としてログを見直す判断が考えられます。

  • 機密性の高いデータをAzureで扱っている
  • 金融、医療、行政などの規制対象組織
  • Microsoftから個別通知を受け取った
  • 不審なサインインや管理操作をすでに検知している
  • インシデント対応規程でCritical CVEの確認が義務付けられている

Azure Activity Logでは、サブスクリプションやリソースに対する管理操作などを確認できます。(Microsoft Learn)

確認する場合は、次の観点が候補になります。

  • 想定していないリソース閲覧や管理操作
  • 不審なロール割り当て
  • 身に覚えのない設定変更
  • 不審なリソース作成や削除
  • 通常と異なる管理者アカウントの利用
  • Microsoftから通知された時刻周辺の操作

ただし、CVE-2026-62835は情報漏えい脆弱性です。攻撃によって情報が参照されても、リソース変更が発生しなければ、Azure Activity Logに明確な痕跡が残らない可能性があります。

そのため、「Activity Logに異常がないこと」だけで、情報が一切取得されていないと証明することはできません。ログ調査は補助的な確認であり、Microsoftのサービス側調査や個別通知の代替にはなりません。

「情報漏えい脆弱性」と「実際の情報漏えい」は別

CVEの影響が「Information Disclosure」と分類されていても、それだけで利用企業の情報が実際に漏えいしたことを意味するわけではありません。

区別すべきなのは、次の3点です。

状態意味
脆弱性が存在した情報を不正取得できる技術的な問題があった
攻撃が試みられた誰かが脆弱性を悪用しようとした
情報漏えいが発生した攻撃が成功し、実際に情報が取得された

CVE-2026-62835の公開情報は、脆弱性の存在と技術的な影響を示すものです。公開されているCVEレコードだけでは、個別のAzure利用者について、実際に情報漏えいが発生したかどうかまでは判断できません。

社内説明では、「Azure Portalから情報が漏えいした」と断定するのではなく、次のように表現するのが適切です。

Azure Portalに、権限のない攻撃者が情報を取得できる可能性のある認可不備が存在した。Microsoftによるサービス側の緩和は完了しており、現時点で顧客側の作業は不要とされている。

NVDでCVSS 7.5と9.3が併記される理由

NVDのCVE-2026-62835の画面では、MicrosoftによるCVSS 9.3と、NISTによるCVSS 7.5が併記されています。

評価元CVSS主な違い
Microsoft CNA9.3Scope Changed、Availability Low
NIST NVD7.5Scope Unchanged、Availability None

Microsoftのベクトルは次のとおりです。

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

NISTのベクトルは次のとおりです。

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

両者は、影響範囲を示すScopeと、可用性への影響の評価が異なります。そのため、同じCVEでもスコアに差が生じています。(NVD)

この記事では、対象サービスを提供し、CVEを登録したMicrosoftの評価である9.3を基準にしています。

ただし、対応要否を判断するときは、9.3か7.5かという数値だけでなく、次の情報を併せて確認する必要があります。

  • 実際に利用している製品やサービスか
  • 利用者が更新できる製品か
  • ベンダーによる緩和が完了しているか
  • 顧客側の作業が指定されているか
  • 悪用や個別影響について通知があるか

CVE-2026-62835では、スコアの高さよりも、「Microsoft管理のホスト型サービスであり、Microsoft側の緩和が完了している」という点が対応判断の中心になります。

よくある疑問

Azureを利用しているだけで影響を受けるのか

公開されている対象サービスはAzure Portalです。ただし、具体的にどの機能、画面、利用条件が影響を受けたのかは明らかにされていません。

Azureを利用しているという理由だけで、すべてのリソースやデータが漏えいしたと判断することはできません。Microsoft側の緩和が完了しているため、利用状況を調べてパッチを適用する作業も不要です。

Azure Portalを使わずCLIだけを使っていれば問題ないのか

Azure Portalを日常的に使っていない場合でも、利用者側の対応要否は変わりません。Microsoft側で緩和済みであり、CLI利用者にも追加作業は求められていません。

また、Portalを使っていなかったという事実だけで、テナントが技術的に影響を受けなかったと断定することもできません。

Azureのパスワードを変更すべきか

CVE-2026-62835だけを理由に、全利用者のパスワードを一斉変更する必要はありません。

ただし、不審なサインイン、認証情報の漏えい、Microsoftからの個別通知など、別の根拠がある場合は変更を検討します。

Azure RBACを見直す必要はあるか

このCVEを修正するためのAzure RBAC変更は不要です。

一方、最小権限、定期的なアクセスレビュー、不要な所有者権限の削除などは、CVEとは別に継続すべき基本的なセキュリティ対策です。

Azure Portalを一時的に利用停止すべきか

Microsoftが完全に緩和済みとしているため、CVE-2026-62835を理由にAzure Portalの利用を停止する必要はありません。

根拠なくアクセスを制限すると、障害対応や運用管理に支障が出る可能性があります。

対応判断の最終チェック

CVE-2026-62835への対応は、次のように整理できます。

  • Azure Portal側の脆弱性である
  • 原因は認可処理の不備である
  • ネットワーク経由で情報を取得される可能性があった
  • MicrosoftのCVSS基本値は9.3である
  • Microsoft管理のホスト型サービスである
  • Microsoft側で完全に緩和済みである
  • 顧客が適用する更新プログラムはない
  • Azure設定の変更も不要である
  • パスワードやシークレットの一斉変更も不要である
  • 脆弱性管理台帳への記録と公式情報の確認は推奨される
  • 個別通知や不審な事象がある場合のみ追加調査を行う

結論として、CVE-2026-62835は技術的には深刻度の高い脆弱性ですが、Azure利用者が緊急パッチや設定変更を行う必要はありません。社内では「未対応」ではなく、「Microsoftによるサービス側の緩和完了を確認し、顧客作業なしで対応完了」と記録するのが適切です。(Microsoft Security Response Center)

この記事を書いた人

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

コメント

コメントする

目次