CVE-2026-58275は、Azure DNSで必要な認可処理が欠けていたことにより、事前の権限を持たない攻撃者がネットワーク経由で権限を昇格できる脆弱性です。CVSS基本値は最高の10.0ですが、2026年8月1日時点ではMicrosoftがクラウド側で完全に緩和済みとしており、利用者によるパッチ適用や設定変更は必要ありません。(Microsoft Security Response Center)
ただし、「対応不要」は「何も確認しなくてよい」という意味ではありません。企業や自治体の情報システム担当者は、Microsoftの対応状況を脆弱性管理台帳に記録し、必要に応じてAzureの操作ログを確認できる状態にしておくことが重要です。
この記事では、CVE-2026-58275の内容、CVSS 10でも緊急作業が不要な理由、利用者側で実施すべきことと避けるべきことを具体的に解説します。
CVE-2026-58275は緩和済みで利用者の対応は不要
CVE-2026-58275の公開情報を整理すると、次のようになります。
| 項目 | 内容 |
|---|---|
| CVE番号 | CVE-2026-58275 |
| 対象サービス | Azure DNS |
| 脆弱性の種類 | 必要な認可処理の欠落 |
| CWE | CWE-862：Missing Authorization |
| CVSS基本値 | 10.0／Critical |
| 攻撃経路 | ネットワーク経由 |
| 事前権限 | 不要 |
| ユーザー操作 | 不要 |
| 想定される影響 | 権限昇格、データの整合性とサービス可用性への重大な影響 |
| Microsoftの対応 | クラウドサービス側で完全に緩和済み |
| 利用者側の対応 | 不要 |
NVDに登録されたCVSSベクトルは、CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:H/A:Hです。また、このCVEには、Microsoftが管理するホスト型サービスの問題であることを示す「Exclusively Hosted Service」の表示があります。(NVD)
したがって、Azure DNSを利用している組織が、このCVEだけを理由として緊急メンテナンスを実施する必要はありません。
CVE-2026-58275で何が問題だったのか
CVE-2026-58275の原因は、Azure DNSにおける認可処理の欠落です。
認可とは、利用者やプログラムが特定の操作を実行してよいかを確認する処理です。認証と混同されやすいものの、それぞれの役割は異なります。
| 処理 | 確認する内容 | 具体例 |
|---|---|---|
| 認証 | 誰が操作しているか | Microsoft Entra IDで利用者を識別する |
| 認可 | その利用者が操作してよいか | DNSレコードの変更権限があるか確認する |
たとえば、利用者の識別ができていても、DNSレコードを書き換える権限がなければ、本来は操作を拒否しなければなりません。
CWE-862は、このような重要な操作の前に、必要な認可チェックが実施されていない状態を指します。CVE-2026-58275では、この欠落によって、権限を持たない攻撃者がネットワーク経由で権限を昇格できる可能性がありました。(NVD)
Azure DNSへの影響が重大と評価された理由
Azure DNSは、Azure上でDNSゾーンとDNSレコードを管理するクラウドサービスです。DNSは、ドメイン名をIPアドレスなどの接続先情報に変換するために使われます。(Microsoft Learn)
DNSの設定が不正に変更されると、一般的には次のような問題につながる可能性があります。
- 本来とは異なるサーバーへ通信が誘導される
- Webサイトや業務システムへ接続できなくなる
- メール配送やサービス間通信が失敗する
- DNSレコードを利用する認証処理やサービス検証に影響する
ただし、これらはDNS設定が不正に変更された場合に考えられる一般的な影響です。Microsoftの公開情報では、CVE-2026-58275を利用して具体的にどのレコードや機能を操作できたのか、どのリージョンや期間が影響を受けたのかまでは明示されていません。
公開情報から断定できる範囲と、断定できない範囲を分けて判断する必要があります。
| 公開情報から確認できること | 公開情報だけでは断定できないこと |
|---|---|
| Azure DNSの認可処理に問題があった | 詳細な攻撃手順 |
| ネットワーク経由で権限昇格が可能だった | 対象となったDNS操作やレコード種類 |
| 事前権限や利用者操作が不要だった | 影響を受けたリージョンや期間 |
| 整合性と可用性への影響が高いと評価された | 個別テナントが実際に攻撃されたか |
| Microsoft側で緩和済み | 各組織の環境に不審な変更がなかったか |
CVSS 10でも緊急パッチが不要な理由
CVE-2026-58275で特に混乱しやすいのが、「CVSS 10なのに、なぜ利用者の対応が不要なのか」という点です。
理由は、CVSS基本値と現在の対応状況は別の情報だからです。
CVSS基本値は、脆弱性が未修正の状態で悪用された場合の攻撃条件や影響を評価します。一方、ベンダーがすでに修正・緩和しているか、利用者が更新作業を行う必要があるかまでは、CVSS基本値だけでは判断できません。
CVSSベクトルの意味
CVE-2026-58275のCVSSベクトルを分解すると、次のようになります。
| 指標 | 評価 | 意味 |
|---|---|---|
| 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となっています。(NVD)
しかし、Microsoftが問題のあるクラウド側の処理をすでに緩和しているため、現在の利用者環境で同じ攻撃条件が残っていることを意味するものではありません。
クラウドサービスのCVEは修正後に公開されることがある
Windowsや一般的なサーバー製品では、利用者が更新プログラムを適用して脆弱性を修正します。
一方、Azureのようなクラウドサービスでは、サービスを運用するMicrosoftがバックエンド側を直接修正できます。利用者が操作できない部分で問題が発生した場合、利用者向けの更新プログラム自体が存在しないこともあります。
Microsoftは、重大なクラウドサービスの脆弱性について、利用者の作業が不要であっても透明性確保のためにCVEを公開する方針を示しています。また、「Exclusively Hosted Service」のタグは、Microsoftがホストするサービス内の問題であり、顧客による対応が不要であることを示します。(Microsoft)
そのため、次の2つは矛盾しません。
- 脆弱性そのものの深刻度はCVSS 10
- 現在はMicrosoft側で緩和済みのため、利用者の作業は不要
利用者側で必要な対応と不要な対応
Azure DNSの管理者が取るべき対応を、実務上の判断基準で整理します。
| 対応内容 | 対応要否 | 判断理由 |
|---|---|---|
| Windows UpdateやKBの適用 | 不要 | Azureのホスト型サービス内の問題であるため |
| Azure DNSの再デプロイ | 不要 | Microsoft側で緩和済みのため |
| DNSゾーンの作り直し | 不要 | 利用者側の構成変更は求められていないため |
| DNSレコードの一括再登録 | 不要 | 本CVEの修正にはならないため |
| Azureリージョンの移行 | 不要 | リージョン移行の案内はないため |
| パスワードやシークレットの一斉変更 | 原則不要 | 本CVEだけを理由とした認証情報変更は求められていないため |
| Azure DNSの利用停止 | 不要 | サービス側で緩和済みのため |
| 脆弱性管理台帳への記録 | 推奨 | 対応判断の根拠を残すため |
| Activity Logの確認 | 必要に応じて実施 | 組織の監査基準や不審な事象の有無に応じて判断するため |
| MSRC情報の継続確認 | 推奨 | 公開情報が更新される可能性に備えるため |
不要な設定変更を急いで実施しない
CVSS 10という数字だけを見て、DNSゾーンの削除と再作成、レコードの再登録、アクセスキーの変更などを急いで行うと、かえってサービス停止を引き起こすおそれがあります。
特にDNSレコードには、Webサイト、メール、証明書検証、Microsoft 365、外部SaaSなど、多数のサービスが依存している場合があります。
本CVEに対してMicrosoftが利用者側の作業を求めていない以上、次のような変更は避けるべきです。
- 根拠のないDNSレコードの削除
- DNSゾーンの別サブスクリプションへの緊急移行
- TTLを考慮しないレコード変更
- Azure DNSから他社DNSサービスへの即時移行
- 業務影響を確認しない認証情報の一斉ローテーション
脆弱性対応では、「何か変更すること」ではなく、「必要な変更だけを安全に実施すること」が重要です。
対応不要でも脆弱性管理の記録は残す
企業や自治体では、利用者側の作業が不要なCVEでも、対応判断の記録を残しておくことを推奨します。
記録がないと、後日監査やセキュリティ点検でCVE番号が検出された際に、「未対応なのか、対応不要と判断したのか」が分からなくなるためです。
脆弱性管理台帳やチケットには、次のように記録できます。
CVE番号：CVE-2026-58275
対象サービス：Azure DNS
深刻度：CVSS 10.0／Critical
脆弱性分類：CWE-862 認可の欠落
対応判定：ベンダー側で完全に緩和済み
利用者側作業：不要
判断根拠：Microsoft Security Response Centerの公開情報
確認日：2026年8月1日
追加対応：通常監視を継続。不審なDNS変更がある場合のみログを調査この記録を残しておけば、脆弱性スキャナーや外部監査でCVE-2026-58275を指摘された場合にも、明確な根拠を示せます。
Activity Logを確認した方がよいケース
Microsoftは利用者側の作業を求めていないため、すべての組織が緊急ログ調査を行う必要はありません。
ただし、次のような場合は、通常のインシデント確認としてAzure Activity Logを確認する価値があります。
- DNSレコードが意図せず変更されていた
- Azure DNSを利用するサービスで原因不明の接続障害が発生した
- 身に覚えのない管理操作通知を受信した
- 高い保証水準が必要なシステムでAzure DNSを利用している
- 社内規程で重大なCVE公開時のログ確認が義務付けられている
- Microsoftやセキュリティ監視サービスから個別の通知を受けた
Azure Activity Logの確認手順
Azure Activity Logには、Azureリソースに対して実行された作成、更新、削除などの管理操作が記録されます。ログはAzureによって自動収集され、Azure portalやLog Analyticsから確認できます。(Microsoft Learn)
Azure portalでは、次の手順で確認します。
- Azure portalで「モニター」を開く
- 「アクティビティ ログ」を選択する
- 対象のサブスクリプションまたはリソースグループを指定する
- 調査対象期間を設定する
- Azure DNSのリソースに絞り込む
- 作成、更新、削除に関する操作を確認する
- 実行者、日時、状態、対象リソースを確認する
特に確認したい項目は次のとおりです。
| 確認項目 | 見るべきポイント |
|---|---|
| 操作名 | DNSゾーンやレコードに対する書き込み・削除操作か |
| 実行者 | 管理者、サービスプリンシパル、マネージドIDのどれか |
| 実行日時 | 保守作業やデプロイの時間帯と一致するか |
| 状態 | 成功した操作か、失敗した操作か |
| 対象リソース | 想定しているDNSゾーンやレコードか |
| 相関ID | 関連する一連の操作を追跡できるか |
不審な操作が見つかった場合は、CVE-2026-58275だけに原因を限定せず、管理者アカウント、サービスプリンシパル、CI/CD、Infrastructure as Code、自動化スクリプトなども含めて調査します。
Activity Logに異常がないことは、あらゆる攻撃がなかったことの完全な証明にはなりません。あくまで、Azureの管理操作に不審な履歴がないかを確認する手段として利用してください。
Azure DNSの権限を見直す場合の判断基準
CVE-2026-58275への直接的な修正作業は不要ですが、この機会にAzure DNSの権限を確認することは、一般的なセキュリティ強化として有効です。
ただし、CVE対応と通常の権限管理を混同しないことが重要です。
Owner権限を安易に付与しない
DNSレコードを管理するだけの担当者に、サブスクリプションやリソースグループのOwner権限を付与する必要はありません。
Azureには、DNS管理用の組み込みロールがあります。
| 組み込みロール | 主な用途 |
|---|---|
| DNS Zone Contributor | DNSゾーンとレコードセットを管理する |
| Private DNS Zone Contributor | Azure Private DNSゾーンのリソースを管理する |
DNS Zone ContributorはDNSゾーンやレコードセットを管理できますが、他の利用者にアクセス権を付与する権限はありません。Private DNS Zone Contributorも、Private DNSゾーンの管理範囲に限定されたロールです。(Microsoft Learn)
実務では、次の基準で権限を割り当てます。
- DNSレコードの更新だけを行う担当者にはDNS管理用ロールを使う
- 権限付与が必要な管理者だけにUser Access Administratorなどを付与する
- CI/CDには必要なDNSゾーンだけをスコープとして指定する
- 個人アカウントよりマネージドIDやサービスプリンシパルを利用する
- 不要になったロール割り当てを定期的に削除する
これはCVE-2026-58275を修正するための作業ではなく、別の認証情報漏えいや設定ミスが発生した場合の影響を小さくするための対策です。
CVE-2026-58275でよくある疑問
CVSS 10なら社内インシデントとして扱うべきですか
CVSS 10という理由だけで、直ちに自社のセキュリティインシデントと判断する必要はありません。
インシデント判定では、少なくとも次の情報を組み合わせます。
- 脆弱性が現在も悪用可能か
- ベンダー側で修正・緩和されているか
- 利用者側の作業が求められているか
- 自社環境で不審な操作や障害が確認されているか
- ベンダーから個別通知を受けているか
CVE-2026-58275は深刻度の高い脆弱性ですが、Microsoftによる緩和済みであり、顧客側の対応は不要とされています。したがって、不審な事象が確認されていない場合は、「ベンダー対応済み」として脆弱性管理上の記録を残す対応が適切です。(Microsoft Security Response Center)
パスワードや証明書を変更する必要はありますか
CVE-2026-58275だけを理由として、パスワード、クライアントシークレット、証明書などを一斉に変更する必要はありません。
ただし、次のような別の侵害兆候がある場合は、通常のインシデント対応として変更を検討します。
- 管理者アカウントへの不審なサインイン
- 身に覚えのないDNSレコード変更
- サービスプリンシパルの資格情報漏えい
- 不正なロール割り当て
- DNSを利用した通信先の不正な変更
認証情報の変更は、侵害の根拠や組織のセキュリティポリシーに基づいて判断してください。
Azureサポートへ問い合わせる必要はありますか
通常は、CVE-2026-58275について確認するためだけにAzureサポートへ問い合わせる必要はありません。
次の場合は、問い合わせを検討します。
- Microsoftの案内と自社契約の適用範囲が判断できない
- DNSレコードに説明できない変更がある
- Azure DNSに関連する障害が継続している
- 個別のセキュリティ通知を受け取った
- 監査上、ベンダーから書面での回答が必要である
問い合わせ時には、サブスクリプションID、対象DNSゾーン、発生日時、Activity Logの相関IDなどを準備すると、調査を進めやすくなります。
対応不要なのにCVEが公開されるのはなぜですか
クラウドサービスでは、ベンダーが利用者に代わってバックエンドを修正できます。そのため、CVEの公開時点ですでに問題が解消され、利用者が更新作業を行う必要がないケースがあります。
Microsoftは、利用者の作業が不要な場合でも、重大なクラウドサービスの脆弱性を透明性の観点から公開する方針を示しています。CVEの公開は「現在も未修正」という意味ではなく、「重大なセキュリティ上の問題が確認され、追跡可能な形で情報が公開された」という意味です。(Microsoft)
まとめ：点数ではなく現在の修正状態と対応要否で判断する
CVE-2026-58275は、Azure DNSの認可処理が欠けていたことにより、事前権限のない攻撃者がネットワーク経由で権限を昇格できる脆弱性です。CWE-862に分類され、CVSS基本値は10.0と評価されています。(NVD)
一方で、Microsoftはクラウドサービス側で完全に緩和済みとしており、Azure DNS利用者によるパッチ適用、設定変更、DNSゾーンの再作成などは必要ありません。(Microsoft Security Response Center)
Azure DNSの管理者が実施すべきことは、次の3点です。
- Microsoft側で緩和済みであることを脆弱性管理台帳に記録する
- 不審なDNS変更や障害がある場合だけActivity Logを確認する
- 通常のセキュリティ対策としてAzure RBACの最小権限を維持する
CVSSの数値だけで緊急変更を判断せず、「現在も悪用可能なのか」「ベンダー側で修正済みか」「利用者側の作業が必要か」を分けて確認することが、安全で無駄のない脆弱性対応につながります。
コメント