CVE-2026-124194 Outlook｜中程度でも優先する理由と更新確認

はじめに

Microsoft は 2026 年 11 月 10 日（米国時間）、Outlook のなりすまし脆弱性 CVE-2026-124194 を修正しました。CVSS v3.1 の基本値は 6.5（Medium）ですが、Microsoft が悪用を検知しており、同日に CISA の KEV カタログにも登録されています。Windows Update の適用状況とは別に、Office の更新チャネルとビルドを確認して修正を完了させることが対応の中心です。

同月の更新では 1,000 件を超える CVE が公開されており、CVSS の点数順に対応を並べると、Medium の脆弱性は後回しになりがちです。また、Windows の月例更新の準拠率を見て「Office も更新済み」と判断してしまうケースも少なくありません。本記事では、CVSS 6.5 の脆弱性を優先する根拠と、自社の Outlook が修正済みかを実際のビルドで確認する方法を整理します。

結論として、影響対象の Outlook を利用する端末は、悪用の確認と KEV 登録を根拠に、通常の月例サイクルより前倒しで修正ビルドへ更新し、実際のビルドで適用を確認します。あわせて外向き SMB と NTLM の制限状況を点検し、不審なメッセージファイルを開いた可能性がある端末は個別に調査します。

CVE-2026-124194 Outlook の概要と攻撃成立条件

公表されている脆弱性情報

Microsoft が CNA として登録した CVE レコードと、CISA KEV の登録情報をもとに整理します。

参考: CVE Record（CVE-2026-124194）
“Product ui does not warn user of unsafe actions in Microsoft Office Outlook”
（Microsoft Office Outlook の製品 UI が、安全でない操作について利用者に警告しない）
https://www.cve.org/CVERecord?id=CVE-2026-124194

攻撃成立条件とプレビューペインの扱い

Microsoft の説明では、攻撃者が細工したメッセージファイルを送り付け、利用者に影響を受けるバージョンの Outlook で開かせる必要があります。プレビューペインで表示しただけでは攻撃は成立しないとされています。ファイルを開いた際、外部への接続について警告が表示されないまま、攻撃者が用意したサーバーへ NTLMv2 認証情報が送信される可能性があります。

CVSS ベクターを読むと、認証不要でネットワーク経由の攻撃が可能（AV:N、PR:N）な一方、利用者の操作が必要（UI:R）で、影響は機密性に限られます（C:H、I:N、A:N）。基本値が 6.5 にとどまるのは、主にこの 2 点によるものです。なお、どのファイル形式のどの処理で外部接続が発生するかといった攻撃の内部処理は公表されていません。

Outlook NTLM 認証情報の漏洩と認証成功は別の段階

本脆弱性で起こり得るとされているのは、認証情報の外部送信までです。その後の段階は攻撃者の行動と自社環境の設定に左右されるため、次のように区別して評価します。

① 認証情報の外部送信・取得

攻撃者のサーバーが受け取るのは、NTLM のチャレンジに対する応答（一般に Net-NTLMv2 と呼ばれるもの）です。パスワードそのものでも、パスワードから算出される NT ハッシュそのものでもありません。

② 取得した情報の悪用可能性

一般に、2 つの悪用が考えられます。1 つは、取得した応答をもとにオフラインでパスワードを推測する方法で、成否はパスワードの強度に左右されます。もう 1 つは、認証のやり取りが行われているその場で別のサーバーへ中継する NTLM リレーで、成否は SMB 署名や拡張保護などの設定に左右されます。保存した応答を後から別のサーバーへの認証にそのまま再利用することはできず、NT ハッシュそのものを使う Pass-the-Hash とも異なります。

③ 認証の試行

推測したパスワードや中継によって、社内システムやクラウドサービスへの認証が試みられる段階です。

④ 認証成功

多要素認証、NTLM の制限、アカウントの状態などによっては失敗します。試行と成功は別の事象として確認します。

⑤ その後の権限悪用や横展開

影響の大きさは、該当アカウントの権限と、そのアカウントで到達できるシステムの範囲に依存します。

外部送信が起きたことは、認証成功やアカウント侵害が起きたことを意味しません。ただし、外部送信の可能性がある端末では、③以降が起きている前提で調査とパスワード対応を検討します。

CVSS 6.5 でも優先する理由と CISA KEV の位置づけ

CVSS と更新優先度を分けて判断する

CVSS の基本値は脆弱性の技術的な特性を表す指標で、実際に悪用されているか、自社でどれだけ使われているかは含みません。CVE レコードの時間的指標では、悪用コードの成熟度が E:H（High）とされています。更新の優先度は、基本値に次の観点を加えて判断します。

これは、同月に公開された Critical の脆弱性を後回しにしてよいという意味ではありません。外部に公開された資産で、自動化された悪用が可能な Critical の脆弱性は、引き続き最優先の対象です。Office の更新は Windows の更新と配信経路が異なるため、OS 側の対応と並行して進められます。

CISA KEV 登録と対応期限の読み方

CISA KEV の原票では、本脆弱性は次の内容で登録されています。

参考: CISA Known Exploited Vulnerabilities Catalog
“Apply mitigations in accordance with vendor instructions”
（ベンダーの指示に従って緩和策を適用する）
https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-124194

11 月 24 日という期限は、2026 年 6 月 10 日に発出された BOD 26-04 にもとづき、米国の連邦民間行政機関に適用されるものです。BOD 26-04 は、外部への公開状況、KEV への登録、悪用の自動化可能性、技術的影響の 4 つの要素から対応期限を決める枠組みで、従来の BOD 22-01 を置き換えています。日本の民間企業に法的な対応義務を課すものではありません。社内の目標期限を決める際の参考として扱うのが妥当です。

なお、CISA の SSVC 評価が「Automatable: no」となっているのは、利用者の操作を必要とする攻撃成立条件と整合します。大量の自動攻撃には向かない一方、標的を絞ったメールで利用される形は否定されていません。攻撃主体、規模、被害範囲、侵害指標（IOC）は、本記事の執筆時点で公表されていません。

Microsoft 365 Apps 脆弱性の影響対象と修正ビルド

CVE レコードで影響対象とされている製品と、修正済みビルドは次のとおりです。いずれも 32 ビット版と 64 ビット版が対象です。

Office LTSC は、表のビルド未満が影響を受けるとされています。Microsoft 365 Apps の各チャネルの修正ビルドは、Microsoft 365 Apps のセキュリティ更新一覧の 2026 年 11 月 10 日の項と、日付別の更新履歴で確認します。

対象の 3 製品はいずれも Click-to-Run 形式で更新される製品で、修正の有無はビルド番号で判断します。製品別の修正 KB 番号は、本記事の執筆時点で確認できていません。

一覧にない製品を、無条件に「影響なし」と判断しないことも重要です。新しい Outlook for Windows、Outlook on the web、Mac 版やモバイル版は一覧に含まれていませんが、これは公開時点の一覧に記載がないことを示すにとどまります。最新の対象製品と回避策の記載は MSRC のアドバイザリーで確認してください。また、Office 2016 と Office 2019 は 2025 年 10 月 14 日にサポートが終了しています。ただし、公式のセキュリティ更新一覧には、サポート終了後も Microsoft の裁量で Office 2019 に更新を提供する場合があると記載されており、Office 2019 Volume Licensed のビルドも引き続き掲載されています。この更新に CVE-2026-124194 の修正が含まれるかは、CVE レコードの対象製品に Office 2019 が記載されていないため、本記事では判断していません。一覧に記載がないことを「修正不要」と読み替えず、サポート対象製品への移行を進めます。

Outlook 更新確認の手順と Office 更新チャネル

Windows Update と Office 更新は別に管理する

Click-to-Run 形式の Office は、Windows Update ではなく、Office 自身の更新機能によって Office のコンテンツ配信ネットワーク（CDN）や管理者が指定した配布元から更新されます。そのため、WSUS や Windows Update for Business で OS の準拠率が 100% になっていても、Office が古いビルドのまま残ることがあります。OS の更新準拠率と Office の修正完了は、別の指標として管理します。

Microsoft 365 Apps は Current Channel や Monthly Enterprise Channel など複数の更新チャネルがあり、チャネルごとにバージョンと修正ビルドが異なります。Office LTSC も Click-to-Run で更新されますが、製品ごとに固定されたチャネルで、セキュリティ更新と不具合修正のみが提供されます。ビルド番号の大小比較は、同じチャネル・同じバージョンの中でのみ意味を持ちます。

確認から再確認までの 7 つの手順

管理ツールを使えない端末で状態を確かめる補助的な方法として、Click-to-Run の構成情報をレジストリから読み取る方法があります。読み取り専用の操作で、出力の VersionToReport がビルド、Platform がビット数、CDNBaseUrl が更新チャネルに対応します。

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration' | Select-Object ProductReleaseIds, Platform, VersionToReport, CDNBaseUrl, UpdateChannel

このレジストリの読み取りは、Microsoft が本 CVE の確認手順として示したものではありません。結果は数台で Outlook の［Office アカウント］画面の表示と突き合わせてから、一括確認に使うことをおすすめします。

NTLM 漏洩リスクへの追加対策と侵害調査

主要な対策は Office の更新です。ここで紹介する対策は、MSRC が本 CVE 固有の回避策として示したものではなく、NTLM 認証情報の外部送信全般に対する多層防御として位置づけます。

外向き SMB と NTLM 認証の監査・制限

Microsoft の SMB 通信の保護に関するガイドでは、境界のファイアウォールでインターネット向けの TCP 445 を遮断することが推奨されています。Azure Files など正当な利用がある場合は、宛先を限定した例外として扱います。ただし、NTLM 認証は SMB 以外のプロトコルでも行われる場合があるため、445 の遮断だけですべての経路を防げるとは限りません。

端末から外部への NTLM 認証は、グループポリシーの Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers で監査・制限できます。設定値は「Allow all」「Audit all」「Deny all」の 3 つです。NTLM を一律に禁止すると既存の業務システムが認証できなくなる可能性があるため、次の順で段階的に進めます。

1. 「Audit all」を設定し、外向きの NTLM 認証を記録します。記録先は Windows イベントログの Microsoft-Windows-NTLM/Operational です。
2. 記録から既存の NTLM 利用先を棚卸しし、Kerberos へ移行できるものと、移行できないものを分けます。
3. 移行できない利用先は「Add remote server exceptions for NTLM authentication」の例外リストに登録します。
4. 業務影響がないことを一部の端末で確認してから、「Deny all」を段階的に適用します。

外向き NTLM の監査で記録されるイベント（イベント ID 8001 など）と、NTLM 無効化の進め方は、Microsoft の Active Directory Hardening Series – Part 8 でも解説されています。

不審なファイルを開いた可能性がある端末の調査

修正前に不審なメッセージファイルを開いた可能性がある場合は、次の順で確認します。

• メールゲートウェイの受信ログから、該当するメールと添付ファイルの受信者を特定する
• ファイルを開いた端末、利用者、時刻と、その時点の Outlook のビルドを記録する
• ファイアウォール、プロキシ、EDR のログで、同時刻帯に端末から外部への SMB や HTTP の不審な接続がないかを確認する
• 該当アカウントが特権アカウントか、どのシステムへ到達できるかを確認する
• 外部送信の可能性が否定できない場合は、パスワードを変更し、ドメインコントローラーの NTLM 認証の記録（イベント ID 4776、認証パッケージが NTLM のイベント ID 4624 / 4625）やクラウドのサインインログで、不審な認証の試行と成功を区別して確認する

攻撃の兆候が確認された場合は、自社のインシデント対応手順に沿って端末の隔離や証拠保全を進めます。Office の更新は今後の悪用を防ぐ対策で、過去に起きた外部送信や侵害を解消するものではありません。侵害指標は公表されていないため、新たな情報は MSRC と CISA の最新の公式資料で確認してください。

ログに記録がない場合の考え方

ログに記録がないことだけで、外部送信や侵害を否定することはできません。NTLM の監査は事前に有効化していなければ記録されず、ファイアウォールが許可した通信を記録しない設定になっている場合もあります。社外のネットワークから直接インターネットへ接続している端末の通信は、社内のプロキシやファイアウォールに記録が残りません。ログの保存期間も含めて、確認できた範囲と確認できなかった範囲を分けて記録します。

今回の調査で NTLM の監査が未設定だと判明した場合は、次の脆弱性に備えて「Audit all」の設定から始めておくと、調査の材料が残るようになります。

まとめ

CVE-2026-124194 は CVSS 6.5 の Medium ですが、悪用が検知され KEV にも登録されているため、点数だけで後回しにせず優先して対応すべき脆弱性です。対応の中心は、Windows Update とは別に Office のチャネルとビルドを確認し、修正ビルドへの更新を実際の端末で確かめることです。

• 細工されたメッセージファイルを開くと、警告なしに NTLMv2 認証情報が外部へ送信され得る脆弱性
• プレビューペインのみでは攻撃が成立せず、ファイルを開く操作が必要
• 対象は Microsoft 365 Apps for Enterprise、Office LTSC 2024、Office LTSC 2021
• KEV の期限は米国連邦機関向けで、日本企業には社内目標の参考
• OS の更新準拠率とは別に、Office の実ビルドで修正完了を確認
• 外部送信と認証成功・侵害は別の段階として調査
• 外向き SMB と NTLM は監査から始め、段階的に制限

以上、最後までお読みいただきありがとうございました。