オンプレミスExchange ServerのCVE-2026-62911。CVSS 8.0でも優先度が上がる理由と更新後に残る確認作業

2026年8月の月例更新で、オンプレミスのMicrosoft Exchange Serverに認証バイパスの修正が入りました。CVE-2026-62911です。MSRCの分類はCWE-294(キャプチャとリプレイによる認証バイパス)、深刻度はCritical、CVSSの基本値は8.0で、悪用に成功した攻撃者は全Exchangeユーザーのメールボックスを乗っ取り、メールの送信と閲覧、添付ファイルのダウンロードができるとMSRCのFAQに書かれています。

一方でMSRCの表示は、悪用の確認も公開も「No」、Exploitability Indexは「Exploitation Less Likely」です。数字と表示だけを見ると急ぎではないように読めます。この記事は、オンプレミスExchangeを運用する情報システム部門に向けて、一次情報で確認できた事実と、確認できていない伝聞を分けたうえで、優先度をどう決め、更新適用のあとに何を確認するかを整理します。記述は執筆時点(2026年9月7日)に参照できた内容に基づきます。

一次情報で確認できた内容の早見表#

先に、MSRC、NVD、Microsoft Learn、CISA、Shadowserverの公開情報で確認できた範囲を並べます。

この表で注意して読みたいのが、悪用の状況の行とSSVCの行です。MSRCの「Exploitation Less Likely」と、CISAがNVDに載せているSSVCの「poc」は、同じCVEについて別の方向を向いています。この食い違いが、優先度づけを難しくしています。

MSRCが公開した事実の範囲#

MSRCが公開しているのは、脆弱性の説明、CWEの分類、CVSSのベクタ、影響を受ける製品と修正ビルド、そしてFAQが1件です。説明文は「Authentication bypass by capture-replay in Microsoft Exchange Server allows an authorized attacker to elevate privileges over a network」で、権限を持つ攻撃者がネットワーク越しに特権を昇格できる、という形になっています。FAQは、悪用に成功した攻撃者が得る権限として、全Exchangeユーザーのメールボックスの乗っ取り、メールの送信、メールの閲覧、添付ファイルのダウンロードを挙げています。

書かれていないこともあります。どのエンドポイントのどの処理に欠陥があったのか、成立に必要な前提条件は何か、悪用の兆候をどこで見るのか、といった運用側が知りたい情報はMSRCのページにありません。回避策と緩和策の欄も空で、改訂履歴は2026年8月11日の初版1件だけです。つまり、Microsoftが提示している対処は更新の適用だけということになります。

第三者による解説には、インターネットから到達できるMRSProxyのエンドポイントでExtended Protection for Authenticationが強制されず、ExchangeのマシンアカウントのNTLM認証をリレーされると認証を迂回できる、という趣旨の記述があります。ただしこれはMicrosoftが確認した説明ではありません。この記事では、この経路を前提条件として扱いません。前提条件に賭けた判断(たとえば「MRSProxyを無効にしているから対象外だろう」)は、Microsoftが成立条件を公表していない以上、根拠を持ちません。防御側の行動は、更新の適用を軸に組み立てます。

MSRCのCVE-2026-62911のページは、脆弱性を「Authentication bypass by capture-replay in Microsoft Exchange Server allows an authorized attacker to elevate privileges over a network.」と説明し、CWEをCWE-294、SeverityをCritical、ImpactをElevation of Privilege、CVSSの基本値を8.0、現状値を7.0、ベクタを「CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C」としています。Publicly disclosedとExploitedはいずれもNo、Exploitabilityの評価は「Exploitation Less Likely」です。FAQには「The attacker would be able to take over the mailboxes of all Exchange users, attackers can send emails, read emails, download attachments.」と記載されています。

NTLMリレーとExtended Protectionの関係で認証が迂回される機構#

CWE-294は、認証のやり取りを捕まえて別の相手に投げ直すことで、本人であることの確認をすり抜ける欠陥を指します。Windows環境で典型的なのがNTLM認証のリレーです。機構を一文で書くと、あるサーバーへ向けて発行された認証応答を、攻撃者が中継して別のサーバーへ送り込むと、送り先のサーバーは中継元を正規の利用者だと解釈してしまう、という話です。認証応答そのものは正しく作られているため、受け取った側からは正規の認証と区別が付きません。

この中継を成立させないための仕組みが、Windows Extended Protection for Authenticationです。Microsoft Learnの「Exchange Server support for Windows Extended Protection」は、Extended ProtectionがWindows Serverの既存の認証を強化し、認証のリレー攻撃と中間者攻撃を緩和すると説明しています。緩和はChannel Binding Token(CBT)を通じて指定されるチャネル結合の情報を使って実現され、CBTは主にTLS接続で使われる、という記述です。噛み砕くと、認証応答の中に「どのTLSチャネルの上で行われた認証か」という情報を埋め込み、受け取った側がそれを検証します。別のチャネルへ中継された応答は結合情報が合わないため、検証で落ちます。

同じページに、仮想ディレクトリごとのExtended Protectionの取りうる値が整理されています。NoneはIISがCBTの検査をしない状態、AllowはCBTの検査を有効にするが必須にはしない状態で、Extended Protectionに対応するクライアントとは安全に通信しつつ対応しないクライアントも受け入れます。RequireはCBTの検査を必須にし、対応しないクライアントを遮断します。PowerShellのSet-WebServicesVirtualDirectoryのリファレンスでは、対応するパラメータExtendedProtectionTokenCheckingの既定値がNoneと明記されています。

ここで実務上の勘所になるのが、Microsoftが推奨している設定値そのものです。同ページの表で、Default WebsiteのEWS仮想ディレクトリの推奨値はRequiredではなく、UIではAccept、スクリプトではAllowとされています。つまりフロントエンドのEWSは、既定の推奨構成でもCBTの検査が必須ではありません。加えて、Hybrid Agentを使うModern Hybrid構成では、公開に使われているExchangeサーバーのフロントエンドEWS仮想ディレクトリでExtended Protectionを有効にしてはならない、と明記されています。有効にするとメールボックスの移動や空き時間情報の取得といったハイブリッドの機能が壊れるためです。

MRSProxyのエンドポイントは、このEWS仮想ディレクトリの中に置かれています。Microsoft Learnの「Enable the MRS Proxy endpoint for remote moves」は、メールボックスレプリケーションサービス(MRS)のプロキシエンドポイントがフォレスト間のメールボックス移動と、オンプレミス組織とMicrosoft 365の間のリモート移動移行に必要であり、Exchange Web Services(EWS)仮想ディレクトリの設定で有効にする、と説明しています。Extended Protectionの強制が緩い場所と、ハイブリッド運用で外部からの到達が必要になる場所が重なっている、という構図です。攻撃者から見て狙いやすい面がここに生まれます。

Microsoft Learnの「Exchange Server support for Windows Extended Protection」は、Extended Protectionについて「Windows Server の既存の認証を強化し、認証のリレー攻撃や中間者(MitM)攻撃を緩和します。この緩和は、主にTLS接続で使用されるChannel Binding Token(CBT)を通じて指定されるチャネル結合の情報を利用して実現されます」と説明しています。Extended Protectionの設定値については、Noneが「IISはCBTの検査を行わない」、Allowが「CBTの検査は有効だが必須ではない」、Requireが「CBTの検査が必須で、Extended Protectionに対応しないクライアントを遮断する」と定義されています。仮想ディレクトリごとの推奨値の表では、Default WebsiteのEWSがAccept(UI)ないしAllow(スクリプト)、Exchange BackendのEWSがRequiredとされています。またModern Hybrid構成については「Hybrid Agent を経由して公開されている Exchange サーバーでは、フロントエンドの EWS 仮想ディレクトリで Extended Protection を有効にしてはなりません」と明記されています。

念のため補足すると、Extended Protectionが有効なら今回の脆弱性の影響を受けない、とは書けません。Microsoftはそのような条件を公表していません。Extended Protectionは、この種の欠陥が生まれたときに被害の成立を難しくする土台であって、個別のCVEの回避策として案内されているものではない、という位置づけで扱います。

CVSSベクタとExploitability Indexの読み方#

CVSSの数字だけを見て優先度を決めると、この脆弱性は取りこぼしやすくなります。ベクタを分解します。

PR:LとUI:Rが付いているため、基本値は8.0に収まっています。この2つがPR:NとUI:Nだったなら9点台になっていた計算です。Microsoftが深刻度をCriticalと表示しているのに基本値が8.0に留まるのは、この2要素が効いているからです。

現状値(Temporal Score)は7.0で、内訳はE:U(Exploit Code Maturity: Unproven)、RL:O(Remediation Level: Official Fix)、RC:C(Report Confidence: Confirmed)です。E:Uは、実証コードが利用可能でないか、理論上のものにとどまる、という評価です。MSRCのExploitability Indexの表示「Exploitation Less Likely」も同じ方向を向いています。

ここに、別の一次情報が別の評価を置いています。NVDのCVE-2026-62911のページには、CISAがADPとして付与したSSVC 2.0.3の判定が載っており、exploitationがpoc、automatableがno、technicalImpactがtotalとなっています。SSVCのpocは、公開された実証コードが存在するか、悪用の方法がよく知られている状態を指します。またNVDの参照リンクには、CISAのADPが追加した、CVE番号を冠した公開リポジトリが1件含まれています。

同じCVEについて、ベンダーの現状値は「実証されていない」、CISAの判定は「実証コードあり」です。この差をどう扱うかで対応の速度が変わります。MSRCのページは2026年8月11日の初版から改訂されておらず、ベンダーのCVSS現状値は公開時点の評価がそのまま残っています。両者は評価の時点も判断の基準も異なるため、運用側の判断としては悪いほうの想定に寄せて扱うほうが安全です。

深刻度の表示が控えめでも優先度を上げる材料#

CVSSの数字とExploitability Indexは、脆弱性そのものの性質を示す指標です。自組織での優先度は、そこに資産の性質を掛け合わせて決めます。今回のケースで優先度を押し上げる材料を3つに分けます。

1つ目は影響範囲です。MSRCのFAQは、悪用に成功した攻撃者が全Exchangeユーザーのメールボックスを乗っ取り、メールを送信し、閲覧し、添付ファイルをダウンロードできると書いています。メール基盤は、社内のほぼ全員の連絡経路であり、パスワードリセットのリンクや取引先とのやり取り、契約書の添付が集まる場所です。メールを読める状態は、そこから先の横展開の起点になります。メールを正規のドメインから送れる状態は、取引先へのなりすましに直結します。1台の侵害が組織全体に波及する構造を持つ資産では、CVSSの1点差より影響範囲の広さが効きます。

2つ目はインターネットからの到達性です。オンプレミスのExchangeは、社外からのOutlookとOWAの接続、モバイル端末のActiveSync、Microsoft 365とのハイブリッド連携のために、公開された名前とTLSの口を持っていることが多い資産です。Shadowserver Foundationの「Vulnerable Exchange Server Report」は、日次のIPv4全インターネットスキャンとIPv6のヒットリストに基づくスキャンで見つかった脆弱なExchangeサーバーの一覧を配信しており、対象CVEの一覧にCVE-2026-62911が「tagging as of 2026-08-27」として加えられています。インターネットに面した資産は、攻撃側が対象を探す手間がほとんどかからないため、実証コードが出た時点で母集団全体が候補になります。

ここで数値の扱いに注意が要ります。Shadowserver Foundationは2026年9月1日に公式アカウント(Bluesky)の投稿で、2026年8月31日の時点で少なくとも21,899件のIPが未修正として観測され、上位は米国が約6,200件、ドイツが約5,100件だと述べています。あわせて押さえておきたいのは判定の方法です。Shadowserverのレポート説明は「Most vulnerability assessments are made on the version observed.」として、多くの脆弱性判定が観測されたバージョンに基づくと明記しています。つまりこの種の集計は、外から見えるビルド番号による推定であって、実際に悪用可能かどうかの確認ではありません。数字は母集団の規模感として読み、自組織の判断は自組織のビルド番号で行います。

3つ目が実証コードの公開です。CISAのSSVC判定がpocであること、NVDの参照にCISAのADPが追加した公開リポジトリが1件あることから、公開情報として実証コードが流通している状況は確認できます。この記事では所在もコードも扱いません。防御側にとって意味があるのは所在ではなく、「攻撃の試行が広く行われうる段階に入った」という事実のほうです。

Shadowserver Foundationの「CRITICAL: Vulnerable Exchange Server Report」は、このレポートが日次のIPv4全インターネットスキャンとIPv6のヒットリストに基づくスキャンで見つかった脆弱なMicrosoft Exchangeサーバーの一覧を含むと説明しています。対象として列挙されているCVEにはCVE-2020-0688、CVE-2021-26855、CVE-2024-21410、CVE-2025-53786などに加えて「CVE-2026-62911 (see also: MSRCの該当ページ). [tagging as of 2026-08-27]」が含まれます。判定方法については「Most vulnerability assessments are made on the version observed.」と記載されています。

なお、CISAのKnown Exploited Vulnerabilities(KEV)カタログは、執筆時点のカタログ(バージョン2026.09.04、収録1,695件)にCVE-2026-62911を含んでいません。KEVは実際に悪用された証跡が確認された脆弱性のカタログなので、未収録であることは「CISAが悪用の証跡を確認して収録するに至っていない」を意味します。「危険でない」を意味しません。KEVを是正期限の根拠として運用している組織では、今回のCVEはKEV由来の期限が発生しない代わりに、自組織の基準で期限を決める必要があります。

対象の版と修正ビルドの対応表#

MSRCが挙げている影響を受ける製品は4つです。修正ビルドとKB番号は次のとおりで、ビルド番号はMicrosoft Learnの「Exchange Server build numbers and release dates」の記載と一致します。

NVDに登録されている影響範囲は、各製品について「15.01.0.0以上、修正ビルド未満」および「15.02.0.0以上、修正ビルド未満」という形になっています。運用側の確認では、まず各サーバーの版(2016 CU23、2019 CU14、2019 CU15、SE RTM)を特定し、そのうえで上表の同じ行の修正ビルド以上かどうかを見ます。版をまたいでビルド番号だけを比べると誤判定します。たとえば2019 CU15の系列は15.2.1748.xで、CU14の修正ビルド15.2.1544.44より数値が大きいため、CU15の未修正のサーバーを修正済みと読み違えます。Exchange Management ShellでGet-ExchangeServer | Format-Table Name, AdminDisplayVersionを実行すると版が分かりますが、SUの適用状況まで含めた正確なビルドは、後述するHealth Checkerで確認するほうが確実です。

2026年8月のExchangeのセキュリティ更新は、CVE-2026-62911を含めて7件のCVEを修正しています。他の6件はCVE-2026-62910、CVE-2026-62912、CVE-2026-62913、CVE-2026-62914、CVE-2026-62915、CVE-2026-65813で、いずれもMSRCの表示はImportantです。CVE-2026-62911だけがCriticalです。この更新ではOWA Lightが無効化された点も、Microsoft Learnの「Exchange Server supportability matrix」の脚注に記載されています。OWA Lightを使っている利用者がいる環境では、更新の前に周知が要ります。

KB5121573の既知の問題として、ハイブリッド環境の共有メールボックスにラッパーメッセージが現れる事象、公開した予定表(.ics)がカレンダーアプリに対してHTTP 500を返す事象、ハイブリッド環境で代理人が設定されたメールボックスの空き時間情報の取得が失敗する事象が挙げられています。ハイブリッド運用の組織では、更新後に空き時間情報と共有メールボックスの動作確認を作業手順に含めておきます。Exchange Team Blogにはもう1件、適用の順序に関わる既知の問題が挙がっています。バックエンドのメールボックスサーバーだけを8月の更新に上げ、受信するMRSの接続を中継するフロントエンドのサーバーが古いままだと、MRSの移行がTooManyTransientFailureRetriesPermanentExceptionで失敗することがある、というものです。フロントエンド側も同じ更新に上げれば解消するとされているため、組織内のサーバーをまたいで適用を進める場合は、途中で止めない計画にしておきます。

更新の入手経路がExchange 2016と2019で変わる理由#

ここが今回いちばん見落とされやすい部分です。Exchange Server 2016とExchange Server 2019は、2025年10月14日にサポートが終了しています。Microsoft Learnの「Exchange Server supportability matrix」のサポート対象バージョンの表に載っているのはExchange Server SEのRTMだけで、2016と2019については「end of support on October 14, 2025」という警告が置かれています。

サポート終了後の更新は、Extended Security Updates(ESU)のプログラムを通じて提供されています。2026年8月のExchangeのセキュリティ更新を告知したExchange Team Blogは、Exchange 2016と2019の更新を入手できるのはPeriod 2のESUプログラムに登録した組織に限られること、Period 2は2026年5月から10月までの間有効であることを記しています。KB5121576(Exchange 2016 CU23向け)にも「Organizations that are enrolled in the Period 2 Extended Security Update (ESU) program are eligible to receive released security updates until the end of October 2026.」と書かれています。

言い換えると、Exchange 2016または2019を運用していてESUに登録していない組織は、今回の更新を入手できません。オンプレミスのExchangeを運用し続けるなら、この場合に取れる道はESUへの登録かExchange Server SEへの移行になります。Microsoft 365への移行や、メール基盤そのものの置き換えを選ぶ道もあります。Microsoftは「Reminder: Exchange 2016 and 2019 ESU Program Ends in October 2026」という記事で、ESUのタイムラインをこれ以上延長しないこと、2026年10月が終われば現在Period 2のESUを保有していても2016と2019に対する更新は行われないことを明記しています。

Exchange Server SEへの移行そのものは、版の距離が近い場合には重い作業ではありません。同記事は、Exchange 2019のCU14またはCU15からExchange SE RTMへのインプレースアップグレードを、大きな技術的変更ではなくリスクの低い作業だと位置づけています。Exchange 2016はインプレースアップグレードの対象外です。Microsoft Learnの「Upgrading to Exchange Server Subscription Edition (SE)」は、インプレースアップグレードが対応するのはExchange Server 2019のCU14またはCU15からだけで、Exchange 2016からの移行はレガシーアップグレード(新しいサーバーを組織に追加し、メールボックスとリソースを移してから旧サーバーをアンインストールする方式)になると説明しています。今回の更新への対応と並行して、10月末という期限から逆算した計画を立てる段階に来ています。

Microsoft Exchange Team Blogの「Released: August 2026 Exchange Server Security Updates」は、2026年8月のセキュリティ更新がExchange Server Subscription Edition、Exchange Server 2019、Exchange Server 2016に提供されること、Exchange 2016と2019の更新はPeriod 2のESUプログラムに登録した組織のみが入手でき、同プログラムが2026年5月から10月までの間有効であることを記しています。また、更新をすべてのExchangeサーバーとExchange管理ツールを実行しているすべてのサーバーとワークステーションへ導入することを推奨し、ハイブリッド構成については「管理目的だけに使われているサーバーであっても、このSUをExchangeサーバーへ導入する必要がある」としています。適用対象の把握にはExchange Server Health Checkerスクリプトの利用を案内しています。

更新を適用する手順と適用後に確認すること#

更新の適用そのものは通常のSUと同じ流れですが、この脆弱性の性質上、適用の前後で見ておく項目があります。順序を決めて進めます。

Extended Protectionの設定状態を確かめる方法#

更新を当てたあとに残る作業のうち、優先度が高いのがExtended Protectionの状態確認です。理由は2つあります。1つは、この設定が組織内で揃っていないと、認証リレーに対する土台が抜けたサーバーが残るためです。もう1つは、運用の途中で意図せず無効化されることがあるためです。

Microsoft Learnの手順には、証明書を更新するときの流れとして、Extended Protectionを一時的に無効化し、証明書を割り当て、再度有効化する、という3段階が書かれています。ロードバランサでSSLブリッジングを使っている環境では、ExchangeとロードバランサのTLS証明書を揃える必要があるため、この一時的な無効化が発生します。年に一度の証明書更新のたびに無効化される設定は、戻し忘れが起きる設定でもあります。

確認にはMicrosoftが配布しているスクリプトを使います。ExchangeExtendedProtectionManagement.ps1は、CSS-Exchangeのリリースページから取得できます。-ShowExtendedProtectionを付けて実行すると、オンラインの全Exchangeサーバーについて現在のExtended Protectionの設定を表示します。実行にはOrganization Managementロールグループのメンバーであることと、昇格したExchange Management Shellからの実行が必要です。

# 現在の Extended Protection の設定を全サーバーぶん表示する (構成は変更しない)
.\ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection

表示された値を、Microsoft Learnの推奨値の表と突き合わせます。フロントエンド側はDefault WebsiteのAPI、ECP、MAPI、OWA、RPCがRequired、EWSとMicrosoft-Server-ActiveSyncとOABがAllow、AutoDiscoverとPowerShellがOffです。バックエンド側はAutoDiscoverを除いてRequiredが並びます。この並びから外れている箇所があれば、意図した設定なのか、戻し忘れなのかを確かめます。

有効化していない環境で新たに有効化する場合は、前提条件の確認が先です。Microsoft Learnは、Extended ProtectionがSSLオフロードを使う環境では動作しないこと、SSLブリッジングではExchangeとロードバランサで同じ証明書を使う必要があること、組織内の全ExchangeサーバーでTLSの構成を揃える必要があること、SchUseStrongCryptoとSystemDefaultTlsVersionsのレジストリ値を明示的に1にする必要があることを挙げています。NTLMv1を強制している環境ではExtended Protectionと併用できず、クライアント側でパスワードの入力を求められ続ける状態になります。LmCompatibilityLevelは5(NTLMv2応答のみを送信し、LMとNTLMを拒否)が推奨、最低でも3が必要とされています。

Exchange Server 2019 CU14以降のインストーラは、Extended Protectionを既定で有効にします。Exchange Server 2016では既定で有効になっていないため、スクリプトを使った有効化が必要です。Modern Hybrid構成でHybrid Agent経由で公開しているサーバーがある場合は、-ExcludeVirtualDirectories "EWSFrontEnd"を付けて、フロントエンドのEWSを対象から外します。ここを外し忘れると、メールボックスの移動と空き時間情報の取得が止まります。

MRSProxyとEWSの外部到達性を点検する#

更新の適用と並行して、露出面そのものを減らす作業をします。Microsoft Learnの「Enable the MRS Proxy endpoint for remote moves」には、運用の判断に直結する記述があります。フォレスト間の移動やリモート移動移行を行わないのであれば、組織の攻撃対象領域を減らすためにメールボックスサーバーでMRS Proxyのエンドポイントを無効のままにしておくべきだ、というものです。Set-WebServicesVirtualDirectoryのリファレンスでも、MRSProxyEnabledの既定値は$falseと記載されています。

現在の状態は次のコマンドで一覧できます。

# EWS 仮想ディレクトリごとの MRSProxy の有効無効を一覧する
Get-WebServicesVirtualDirectory | Format-Table -Auto Identity, MRSProxyEnabled

# 外部公開されている URL もあわせて確認する
Get-WebServicesVirtualDirectory | Format-List Identity, InternalUrl, ExternalUrl, MRSProxyEnabled, ExtendedProtectionTokenChecking

過去にMicrosoft 365へのメールボックス移行を実施した組織では、移行が終わったあともMRSProxyが有効なまま残っていることがあります。ハイブリッド構成ウィザードが有効にした設定を、移行完了後に戻す手順が抜けているケースです。現在も移行を継続しているかどうかを業務側と確認し、不要であれば無効化します。

なお、ここで確認できるのはEWS仮想ディレクトリの設定としてのMRSProxyの有効無効です。Microsoftは今回のCVEの成立条件を公表していないため、この値がFalseであることをもって関連する露出がないと結論づけることはできません。無効化は攻撃対象領域を減らす施策として行い、判断の軸は更新の適用に置きます。

ネットワーク側の点検も同時に行います。確認したいのは、外部から到達できる必要のあるパスと、実際に到達できるパスがずれていないかです。リバースプロキシやWAF、ロードバランサの公開設定で、/EWS/配下のうち何を通しているかを見ます。ハイブリッド連携が必要な組織でも、Microsoft 365からの通信元は限定できます。Microsoft 365のエンドポイントの一覧は公開されているため、送信元IPでの絞り込みが可能かどうかをネットワークの担当と確認します。

NSAとCISAが豪州ASDのACSCおよびカナダのCanadian Centre for Cyber Securityと共同で2025年10月30日に公開した「Microsoft Exchange Server Security Best Practices」も、方向性としては同じことを述べています。CISAの告知は、この手引きの柱として、利用者の認証とアクセスの堅牢化、強力なネットワーク暗号化の確保、アプリケーションの攻撃対象領域の最小化を挙げ、Microsoft 365への移行後に残っているサポート終了済みのオンプレミスまたはハイブリッドのExchangeサーバーを廃止するよう促しています。あわせて、いわゆる「最後の1台のExchangeサーバー」を残し続けることが継続的な悪用活動にさらされる状態を生む、という指摘があります。

ログから外部アクセスの有無を確認する#

侵害の有無を判断する材料は、Microsoftからは提示されていません。MSRCのページに侵害指標(IoC)の記載はありません。KEVにも執筆時点で収録されていません。公的機関から具体的な検出条件が示されている状況も、執筆時点では確認できていません。それでも、外部からの到達状況を把握しておくことには意味があります。更新を適用するまでの間に、どこからどの経路でアクセスが来ていたかを後から追える状態を作っておくためです。

見るのは主に2種類のログです。1つはIISのアクセスログで、既定ではWindowsのinetpubの配下にサイトごとのフォルダで出力されます。もう1つはExchangeのHttpProxyのログで、Exchangeのインストールパス配下のLoggingフォルダに、EWSやOWAといったプロトコルごとのサブフォルダで出力されます。正確な出力先はインストール時の指定に依存するため、実機で確認します。

見るべき点を挙げます。/EWS/配下へのアクセスについて、送信元IPの分布が想定と合っているかを確認します。ハイブリッド連携をしているならMicrosoft 365側からの通信が主体になるはずで、それ以外の見知らぬ範囲からのアクセスが継続していれば、公開設定の見直しが必要です。認証まわりでは、401が返ったあとに200が返る組み合わせが、想定しない送信元で発生していないかを見ます。時間帯の偏りも手掛かりになります。業務時間外に定常的なアクセスが続いている送信元は、正規の連携なのか棚卸しの対象なのかを確かめる価値があります。

ログの保存期間も確認しておきます。Exchangeのプロトコルログは無期限に残るものではなく、保持の上限に達したものから消えていきます。8月11日の公開から現時点までを振り返りたい場合、その期間のログが残っているかどうかが前提になります。上限の設定値は環境によって異なるため、実機で確認します。残っていない場合は、事後の調査ができない状態だと認識したうえで、SIEMなどへの転送を検討します。

誤解しやすい点を一次情報で確かめる#

対応の現場でよく出る疑問を、確認できる範囲で整理します。

Exchange Onlineは対象かどうか。MSRCの影響を受ける製品として挙がっているのは、Exchange Server 2016 CU23、Exchange Server 2019 CU14、Exchange Server 2019 CU15、Exchange Server SE RTMの4つで、Exchange Onlineは含まれていません。NVDに登録されている影響範囲も同じ4製品です。ただしExchange Team Blogは、Exchange Onlineの利用者について、環境内のExchangeサーバーとExchange管理ツールを入れたワークステーションを更新すること以外に取るべき対応はない、と書いています。裏を返すと、オンプレミスのExchangeサーバーも、Exchange管理ツールを入れたサーバーやワークステーションも1台も存在しない組織だけが、このCVEに関する適用作業を持ちません。

ハイブリッド構成で管理目的にだけ残しているExchangeサーバーはどうか。Exchange Team Blogは、ハイブリッド展開について、管理目的だけに使われているサーバーであってもこのSUをExchangeサーバーへ導入する必要がある、と明記しています。管理専用サーバーは、受信者の管理のためにActive Directoryの属性を書き換える権限を持っており、Exchange組織の中では特別な位置にあります。メールボックスを載せていないことは、更新を省く理由になりません。

Extended Protectionを有効にしていれば対応は不要かどうか。この条件はMicrosoftから提示されていません。前述のとおり、Microsoftが挙げている対処は更新の適用だけです。Extended Protectionの有効化は、この種の攻撃に対する土台として意味がありますが、今回のCVEの回避策として案内されているものではありません。

MRSProxyを無効にしていれば対象外かどうか。これも同じで、Microsoftは成立条件を公表していません。MRSProxyの無効化は攻撃対象領域を減らす施策として独立に価値がありますが、更新を見送る根拠にはなりません。

インターネットに公開していなければ急がなくてよいかどうか。CVSSベクタのAV:Nはネットワーク経由での攻撃を意味しており、その「ネットワーク」がインターネットに限られるわけではありません。社内ネットワークに侵入済みの攻撃者、あるいは業務端末を経由した攻撃者から見れば、内部にあるExchangeも同じネットワーク上の対象です。公開していないことは優先度を1段下げる材料にはなりますが、対応しない理由にはなりません。

Exchange Server SEへの移行を計画に入れる期限#

今回の更新への対応が終わっても、Exchange 2016と2019を運用している組織にはもう1つの期限が残ります。Period 2のESUが2026年10月末で終わり、以降は更新が提供されないという期限です。Microsoftはこれ以上の延長を行わないと明記しています。

11月以降にExchange 2016または2019が本番で動いている状態は、新しい脆弱性が公表されても修正を入手できない状態を意味します。今回のようにインターネットに面した認証周りの脆弱性が出た場合、取れる手が露出の遮断とネットワーク側の制限だけになり、メールの外部との送受信を止めずに対処する余地が小さくなります。

移行の道筋は2つあります。Exchange 2019のCU14またはCU15を運用しているなら、Exchange SE RTMへのインプレースアップグレードが現実的な選択肢です。Microsoftはこれを大きな技術的変更ではなくリスクの低い作業と位置づけています。Exchange 2016を運用している場合はインプレースアップグレードの対象外で、新しいサーバーの構築とメールボックスの移動を伴うレガシーアップグレードの計画になります。所要期間は環境の規模に依存しますが、10月末という期限から逆算すると、9月の時点で着手していないと余裕がありません。

Microsoft 365への移行を選ぶ組織では、最後に残る1台のExchangeサーバーの扱いを決めておきます。前述の4機関の共同手引きは、Microsoft 365への移行後に残っているサポート終了済みのオンプレミスまたはハイブリッドのExchangeサーバーを廃止するよう促しています。ハイブリッドの属性管理のためにオンプレミスのExchangeを残す構成は長く使われてきましたが、残した1台が更新の対象であり続けることは意識しておく必要があります。

検証と調査を行うときの前提#

この脆弱性に関連して自組織の状態を調べるとき、行ってよいことと行うべきでないことの線引きをはっきりさせておきます。

行ってよいのは、自組織が管理するサーバーに対する、設定値とビルド番号とログの確認です。Health Checkerの実行、Get-WebServicesVirtualDirectoryによる設定の読み取り、ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtectionによる設定の表示は、いずれもExchangeやIISの構成を変更しない操作です。ただしCSS-Exchangeのスクリプトは既定で最新版を取得する自動更新の動作を持ち(-SkipAutoUpdateで抑止できます)、実行結果もファイルに出力されるため、まったく何も書き込まない操作ではありません。外部からの到達性の確認も、自社が管理する公開名に対して、自社の合意のもとで行う範囲であれば問題になりません。

行うべきでないのは、公開されている実証コードを本番環境で動かすこと、および他組織のサーバーに対して到達性や脆弱性の確認を許可なく行うことです。前者は復旧不能な状態を作る可能性があり、後者は不正アクセス禁止法などに触れる可能性があります。実証コードを用いた確認が必要な場合は、隔離した検証環境を用意し、対象と期間と範囲について書面で合意を取ってから行います。

外部の事業者に脆弱性診断を依頼する場合も、契約の中で対象範囲と実施方法を明確にします。メール基盤は業務停止の影響が大きい資産なので、検証の時間帯とロールバックの手順を事前に決めておきます。

対応状況の点検リスト#

自組織の現状確認に使える形で並べます。

更新の適用を起点に露出とログまで確認する#

CVE-2026-62911の扱いにくさは、指標の読み方に集約されます。MSRCの表示はCritical、CVSSの基本値は8.0、Exploitability Indexは「Exploitation Less Likely」、CVSSの現状値はE:Uで実証されていない扱いです。一方でNVDに載るCISAのSSVCはexploitation: poc、technicalImpact: totalで、KEVには未収録です。数字だけを機械的に処理すると、優先度は中位に落ち着きます。

判断を分けるのは、指標ではなく資産の性質のほうです。全ユーザーのメールボックスに手が届く経路、インターネットからの到達性、そして実証コードが公開情報として流通している状況。この3つが重なる資産に対して、ベンダーの現状値だけを根拠に後回しにする判断は取りにくくなります。

対応の中身は、更新の適用と再起動、ビルド番号の突き合わせ、Extended Protectionの設定状態の確認、MRSProxyとEWSの露出の見直し、ログでの外部アクセスの確認、という順序に整理できます。更新の適用は出発点で、そのあとに残る作業が半分を占めます。とくにExtended Protectionは、証明書の更新のたびに一時的に無効化される性質を持つ設定なので、更新のタイミングで状態を確かめる習慣を運用手順に組み込んでおくと、次の脆弱性が出たときの土台になります。

そして、Exchange 2016と2019を運用している組織には2026年10月末という期限が控えています。今回の対応で更新の入手経路を確認した組織は、そのまま移行の計画へつなげられる位置にいます。次に同じ規模の脆弱性が公表されたとき、更新を入手できる状態にあるかどうかが、取れる手の数を決めます。