OutlookとWordのRCE脆弱性──メールを「開かずプレビュー」で乗っ取られる仕組みと対処

「添付ファイルは開かなかったから大丈夫」——メールセキュリティの常識として語られてきたこの安心感を、根底から揺るがす脆弱性が公表されました。2026年6月9日のMicrosoft Patch Tuesdayで修正された、OutlookとWordのリモートコード実行（RCE）の脆弱性です。攻撃者視点で見ると怖いのは、メールを「開く」必要すらなく、プレビューペインに表示しただけで悪意あるコードが走りうる点にあります。

この記事では、なぜ「開かずプレビュー」で乗っ取られるのかという攻撃メカニズムを攻撃者の立場から分解し、SOCや情シスが取るべき検知・緩和策を整理します。不安を煽るためではなく、正しく仕組みを理解して、優先順位をつけて対処するための解説です。

何が起きたのか？（概要・なぜ重要か）

今回修正されたのは、Microsoft OutlookとWordに存在するRCE（リモートコード実行）の脆弱性です。RCEとは、攻撃者が標的の端末上で任意のコードを実行できてしまう、影響度の大きい種類の欠陥を指します。Microsoftは2026年6月9日のPatch Tuesdayで、公式の修正パッチを提供済みです。

対象となったCVE（共通脆弱性識別子）は次の3つです。いずれもCVSS（深刻度スコア）はv3.1基本値で8.4、深刻度は「High（高）」と評価されています。

CVE番号	脆弱性の種類	CVSS
CVE-2026-45456	型の取り違え（type confusion）	8.4（High）
CVE-2026-45458	解放後使用（use-after-free）	8.4（High）
CVE-2026-47635	ヒープバッファオーバーフロー	8.4（High）

種類はそれぞれ異なりますが、いずれもWordのレンダリングエンジン（文書を画面に描画する処理）に潜むメモリ破壊系のバグである点が共通しています。そして重要なのは、これらがOutlook classic（従来版Outlook）のプレビュー表示と結びついていることです。執筆時点では、これらの脆弱性が実際の攻撃で悪用された確認はされていません（悪用コードの成熟度は「Unproven＝未実証」）。とはいえ、パッチが出て手口が公になった以上、放置するほどリスクは上がります。

攻撃の仕組み——なぜ「開かずプレビュー」で乗っ取られるのか

普通に考えれば、メールを開かなければ安全なはずです。ではなぜプレビューだけで危ないのか。鍵は、Outlook classicの内部構造にあります。

Outlook classicは、メール本文（特にリッチな書式やオブジェクトを含むコンテンツ）を表示する際に、Wordのレンダリングエンジンを使っています。つまり、メールを「表示」する処理の裏で、実質的にWordが文書を描画しているのと同じことが起きているわけです。プレビューペインに表示するだけでこの描画処理が走るため、悪意ある細工がされたコンテンツを受信すると、ユーザーが添付を開いたりリンクを踏んだりしなくても、描画の段階で脆弱性が発火しうる構造になっています。

攻撃者の視点で並べると、この攻撃チェーンは次のようになります。

・細工したメールを送る: Wordレンダリングの欠陥を突くよう加工したコンテンツをメールに仕込む。
・プレビューで描画させる: 受信者がメール一覧でその行を選んだだけで、プレビューペインに描画処理が走る。
・メモリ破壊を起こす: 型の取り違えや解放後使用といったバグを利用し、メモリの状態を攻撃者の都合のいいように崩す。
・コードを実行する: 崩したメモリ状態を足がかりに、端末上で任意のコードを動かす。

ここで攻撃者にとっての「うまみ」を整理しておきます。通常のフィッシングは「ユーザーが添付を開く」「リンクを踏む」という一手を必要とします。その一手があるからこそ、教育や注意喚起が防御になりえました。ところがプレビュー起因の攻撃は、その一手を飛ばせる。受信者が警戒していても、メールを「見ようとした」瞬間に成立しうるため、人の判断に頼る防御が効きにくくなります。これが、ユーザー操作をほとんど必要としないタイプの脆弱性が危険視される理由です。

なお本記事は防御を目的に構造を解説しています。具体的な細工手順や悪用コードは扱いません。「どの処理が引き金になるか」を知ることが、検知と緩和の設計につながるという立場です。

フィッシング対策の「前提」が崩れる

従来のメールセキュリティ教育は、「怪しい添付は開かない」「不審なリンクは踏まない」を柱にしてきました。これは今も有効です。ただ、プレビュー起因の脆弱性は、その柱の「手前」で成立しうる点に注意が必要です。ユーザーがどれだけ慎重でも、メール一覧をスクロールして表示しただけで発火する余地があるなら、教育だけでは穴を塞ぎきれません。だからこそ、人の注意とは別のレイヤー——パッチ適用とプレビューの制御——が必要になります。

なぜメモリ破壊系のバグが「乗っ取り」につながるのか

今回の3件は、種類こそ違えど「メモリの扱いを誤らせる」系統のバグです。攻撃者がここを足がかりにできる理由を、概念レベルで押さえておくと、検知の勘どころが見えてきます。具体的な悪用手順には踏み込まず、なぜ危険なのかという原理にとどめて説明します。

ソフトウェアは、データを置くメモリ領域を確保したり解放したりしながら動いています。型の取り違え（type confusion）は、本来Aという種類として扱うべきデータを、誤ってBという種類として処理してしまう状態を指します。解放後使用（use-after-free）は、いったん解放して「もう使わない」はずのメモリ領域を、誤って参照し続けてしまう状態です。ヒープバッファオーバーフローは、確保した領域からはみ出してデータを書き込んでしまう状態を指します。いずれも「メモリの状態が、プログラムの想定とずれる」という共通点があります。

攻撃者は、このずれを偶然に任せるのではなく、入力データを精密に細工して「自分の都合のいいメモリ状態」を作り出します。そうして崩した状態を足場に、最終的にプログラムの制御の流れを乗っ取り、任意のコードを実行へと持ち込みます。文書やメールという「ただのデータ」が、なぜ「実行」につながるのか——その答えが、この描画処理の中で起きるメモリ破壊にあります。だからこそ、入力を素直に信用して描画してしまう設計が危ういのです。

守る側にとっての示唆は明確です。第一に、こうしたバグは「データを開いた／表示した」だけで成立しうるため、ファイルの善悪をパターン照合で見分ける従来型の検知では取りこぼしやすい。第二に、発火後は「正規アプリ（OutlookやWord）が、本来しないはずの動きをする」という形で現れます。つまり、入口でブロックしきれない前提に立ち、発火後の異常な振る舞いを捉える検知へ重心を移すことが、現実的な防御になります。

SOC・情シスがやるべき対処

対処の優先順位ははっきりしています。第一にパッチ適用、第二にプレビューの制御、第三に検知の網を張ることです。順に見ていきます。

1. パッチを最優先で適用する

最も確実な対策は、2026年6月9日に提供された公式パッチを適用することです。RCEかつプレビュー起因という組み合わせは、悪用された場合の影響が大きいため、Office製品を使う組織では優先度を上げて配信してください。対象はOutlook classicを含むMicrosoft Officeの各エディション（Office LTSC 2024やMac版Officeなど）に及びます。自組織で使っているバージョンが対象に含まれるかを、Microsoftの公式情報で確認するのが出発点です。

2. プレビューと表示を制御する

パッチ適用までの間や、多層防御の一環として有効なのが表示側の制御です。

・プレビューペインの制限: 信頼できない差出人からのメールについて、自動プレビューの挙動を見直す。組織のポリシーで制御できる場合は適用する。
・Protected View（保護ビュー）の徹底: 外部由来の文書を、まず制限された環境で開く設定を有効にしておく。
・テキスト形式での表示: 環境によっては、メールをリッチな書式ではなくテキスト形式で表示する設定が、描画処理の表面積を下げる助けになる。

3. 検知の網を張る（ASRと挙動監視）

万一に備え、Office製品起点の不審な挙動を検知できるようにしておきます。Officeアプリが子プロセスとして見慣れないプログラムを起動する、スクリプト実行エンジンを呼び出す、といった動きは強い兆候です。Microsoftの攻撃面の縮小（ASR: Attack Surface Reduction）ルールを使うと、Officeアプリからの不審なプロセス生成を抑止・記録できます。EDRやSIEMを併用しているなら、「OutlookやWordのプロセスから、本来あり得ない子プロセスや外部通信が発生した」という相関を検知条件に組み込んでおくと、発火後の動きを早期に捉えられます。

SIEMで監視している場合、具体的な検知ルールの方向性は次のようになります。親プロセスがoutlook.exeやwinword.exeで、子プロセスがコマンドシェル・スクリプトエンジン・PowerShell・任意の未署名バイナリといった組み合わせを、まずアラート候補として拾う。さらに、それらのプロセスから普段と異なる宛先への外部通信が続いていれば、相関スコアを上げる。プレビュー起因の攻撃は「描画→不審な子プロセス→外部通信」という連鎖で現れやすいため、単一イベントではなく一連の流れとして検知する設計が効きます。正規の業務でWordがマクロを動かすケースと区別しきれない場合は、まず検知（アラート）から始め、誤検知の傾向を見ながら抑止（ブロック）へ段階的に移行するのが安全です。

クラウド経由のメールフィルタリングやサンドボックス検査でリスクを前段で削る設計は、姉妹サイトクラウドマスターズ.TOKYOでも扱っています。多層防御の組み立ての参考にしてください。

中小企業でも今日からできること

「ASRルール」「EDR」と聞くと身構えるかもしれませんが、中小企業の情シスでも今日から取れる現実的な一歩があります。

・更新を止めない: Windows UpdateとOffice更新を自動適用に設定し、6月のパッチが当たっているかを確認する。これが最大の防御です。
・古いOutlookの棚卸し: 社内にどのバージョンのOutlook/Officeが残っているかを把握する。更新から取り残された端末が穴になります。
・プレビュー設定の見直し: 全社一律でなくても、外部メールを多く扱う部署からプレビューの扱いを見直す。
・表示形式の検討: 高リスクなアカウントでは、メールのテキスト表示を選択肢として検討する。
・不審メールの報告ルート: 「開かなくても危ないことがある」という前提を共有し、不審なメールはすぐ報告できる窓口を用意する。

どれも高価なツールがなくても始められます。今回の件の本質は、「ユーザー教育だけでは防ぎきれない攻撃がある」という事実です。だからこそ、機械的に効くパッチ適用を最優先に据えるのが正解になります。

対応状況のセルフ点検チェックリスト

自組織の対応状況を、以下で点検してみてください。

・6月パッチの適用状況を把握している: 全端末に2026年6月のOffice更新が当たっているか確認したか。
・対象バージョンを特定している: 社内で使うOffice/Outlookのエディションが影響対象か確認したか。
・未更新端末を洗い出している: 自動更新から外れている端末がないか棚卸ししたか。
・プレビュー・保護ビューの設定を確認している: 外部メールに対する表示制御が有効か。
・Office起点の挙動を監視できる: ASRルールやEDRで不審なプロセス生成を記録できる状態か。

当てはまらない項目があれば、そこが優先対応箇所です。まずはパッチの適用状況から確認しましょう。

よくある誤解と注意点

「これはゼロデイ（修正前から悪用される脆弱性）だから手遅れだ」という受け止めは誤解です。本3件は2026年6月9日のPatch Tuesdayで修正済みであり、執筆時点で実際の悪用も確認されていません。慌てる必要はありませんが、手口が公になったぶん、パッチ未適用のまま放置すると今後狙われる余地が増える——そう捉えるのが正確です。

もう一点、「新しいOutlook（new Outlook）を使っているから無関係」と早合点しないことです。今回の核心はOutlook classicがWordのレンダリングを使う構造にあります。社内に従来版が残っていないか、更新が行き届いているかを確認するのが安全です。最後に、本記事の数値や主張は2026年6月9日時点の公開情報に基づきます。対応判断の際は、必ずMicrosoftの公式情報で対象バージョンと最新の状況をご確認ください。

よくある質問（FAQ）

Q1. メールを開かなくても本当に危ないのですか？
プレビューペインに表示するだけで、Outlook classicがWordのレンダリングエンジンで描画する処理が走ります。その描画段階で脆弱性が発火しうるため、添付を開いたりリンクを踏んだりしなくても成立する余地があります。

Q2. CVSS 8.4はどのくらい危険ですか？
v3.1基本値で8.4は「High（高）」に区分されます。RCEかつユーザー操作をほぼ要しない点を踏まえると、影響度は大きいと考えるべきです。一部メディアは「Critical」と表記しますが、FIRSTの定義上は8.4はHighです。

Q3. すぐにできる対策は何ですか？
最優先は2026年6月9日のパッチ適用です。あわせて、信頼できないメールのプレビュー制御、Protected Viewの徹底、ASRルールでのOffice起点の挙動監視が緩和策になります。

Q4. 個人ユーザーは何をすべきですか？
Windows UpdateとOffice更新を最新に保つことが第一です。自動更新が有効なら、6月の更新が適用されているかを一度確認してください。心当たりのない差出人のメールは、プレビューも含めて慎重に扱いましょう。

Q5. 検知の観点で何を見ればよいですか？
OutlookやWordのプロセスから、本来あり得ない子プロセスの起動、スクリプトエンジンの呼び出し、見慣れない外部通信が発生していないかが手がかりです。ASRルールやEDRでこれらを記録・アラート化しておくと、発火後の動きを早期に捉えられます。

本記事のまとめ

2026年6月9日のPatch Tuesdayで修正された3件のRCE（CVE-2026-45456 / CVE-2026-45458 / CVE-2026-47635、いずれもCVSS 8.4）は、Outlook classicがWordのレンダリングエンジンを使う構造に起因し、メールを開かずプレビュー表示しただけで発火しうる点が特徴です。執筆時点で野良での悪用は確認されていませんが、ユーザー操作をほぼ要しないという性質上、放置のリスクは小さくありません。

攻撃者視点で見れば、これは「ユーザーの一手」を飛ばせる効率の良い攻撃面です。だからこそ守る側は、教育に頼り切らず、機械的に効くパッチ適用を最優先に据える必要があります。そのうえで、プレビューと保護ビューの制御、ASR・EDRによるOffice起点の挙動監視を重ねれば、多層で備えられます。特別な投資をいきなり始める必要はありません。まずは6月パッチの適用状況を確認するところから、自社にできる順番で備えていきましょう。