プレビュー ペインは攻撃対象領域です

Microsoft は、2026年9月8日に、記録上最大規模のセキュリティ修正を公開しました。見出しの数字は集計者によって異なります。Tenable は 964 件の CVE とし、Zero Day Initiative は 972 件、さらに多いとするものもあります。外部項目と Chromium 項目の帰属が異なるためです。8月の合計のおよそ2倍で、約100件が重大と評価され、うち2件はすでに実際の攻撃で悪用されていました。

状況を変える数字は、そのどれよりも小さいものです。

そのリリースに含まれる22件の重大な Microsoft Office パッチのうち12件は、Zero Day Initiative による当月レビューによれば、プレビュー ペインまたは閲覧ペインからトリガーできます。そのうち最も深刻な3件は CVSS スコア 9.8 で、Windows Graphics Component の CVE-2026-77493、Word の CVE-2026-78510、Outlook の閲覧ペインの CVE-2026-78509 です。

何も開かれません。マクロのプロンプトも表示されません。メッセージが届き、クライアントが添付ファイルのプレビューを描画し、コードが実行されます。

レンダリングは解析である

プレビュー ペインは、要求の厳しい役割を担う便利機能です。ファイルの中身を表示するには、まずファイルを分解しなければなりません。コンテナを展開し、レコード構造をたどり、埋め込みフォントや画像を解決し、レイアウトを実行し、結果を描画します。これらの各ステップはすべて、攻撃者が提供したバイト列を読み取り、それについて判断を下すコードです。

それが攻撃対象領域のすべてであり、しかも誰も行為としては考えない部分です。ファイルを読むことは受動的に感じられます。しかし、そうではありません。壊れた長さフィールド、細工されたフォントテーブル、グラフィックスコンポーネントの use-after-free。これらはいずれも文書が信頼されていることを必要とせず、描画されることだけを必要とします。

だからこそ、「サポートされるファイル形式」という表現には注意が必要です。クライアントがプレビューできるあらゆる形式は、そのクライアントがさらされるパーサーであり、頼まれていないのに表示してくれるほど親切なクライアントであるほど、判断が下される前に到達可能なその攻撃対象領域は広がります。

パスに含まれていない判断

世に出回っているユーザー向けガイダンスのほとんどは、開くという行為を前提に作られています。知らない送信者からの添付ファイルは開かないこと。開く前にアドレスを確認すること。クリックする前にリンクにカーソルを合わせること。フィッシングのシミュレーションは、まさにこれを測定します。誰がクリックしたか、誰が開いたか、誰が報告したかです。

それらはすべて、人間の判断が行われる瞬間を対象にしています。今月の重大な Office の不具合12件は、その前段にあります。

これは、認識向上トレーニングが無価値だと言っているのではありません。認識向上トレーニングは、認証情報を狙うフィッシング、ビジネスメール詐欺、請求書ではない請求書を見つけ出します。そして、実際に届くものの大半はそれらです。ここで言いたいのは、ファイル由来のコード実行に対する制御として認識向上トレーニングを使うことはできない、ということです。なぜなら、コードが実行される時点ではユーザーはループの中にいないからです。クリック率が優秀だと報告するプログラムは、この種のバグについては何も語っていません。なぜなら、それが測定したのは、そもそもパス上に存在しなかった判断だったからです。

プレビュー ペインを率直に読むなら、信頼境界を人のメンタルモデルよりも早い段階へ移動させるものだということです。境界はユーザーの判断ではありません。組織が受け入れたファイルが、クライアントがそれをレンダリングする場所に到達した瞬間です。

規制当局はすでにこのソフトウェアを名指ししている

規則の背後にある直感は正しく、そのことは明言する価値があります。

オーストラリアのSignals Directorateは、Essential Eightのパッチ適用期限を、同局自身の言葉を借りれば、インターネットからの信頼できないコンテンツと日常的にやり取りするアプリケーション、つまりオフィス向け生産性スイート、Webブラウザーとその拡張機能、メールクライアント、PDFソフトウェア、セキュリティ製品について強化しました。その期限は1か月から2週間へと変更されました。今月のリリースが最も大きな影響を与えたのはまさにこの一覧にあるソフトウェアであり、示された理由もまさに正しいものです。

シンガポールの期待も、別の角度から同じ方向を向いています。MAS Technology Risk Management Guidelinesは、金融機関に対し、都合のよい時ではなく、重大度を評価し、定められた期間内に修正を展開するパッチ管理プロセスを運用することを求めています。また、CSAのCybersecurity Codes of Practiceは、重要情報インフラに対して同等の期待を課しています。どちらも珍しいものではありません。地域のほぼすべてのフレームワークが、何らかのパッチ適用期間を定めるようになっています。

可変なリリースに対する固定の期間

ここに書かれていない部分があります。

パッチ適用期間は、あなたのプロセスに関する約束です。修正が存在するようになってから、どれだけ速く対応するかを示します。しかし、一度にどれだけの量が届くかについては何も示しません。そして、その2つ目の数値は完全に他者によって決まります。

2週間は、通常の1か月に対しては妥当な約束です。しかし、960件を超える修正を含み、そのうち約100件が重大であり、変更期間、テストサイクル、休暇中のアプリケーション所有者、そして営業時間中に再起動できない少数のシステムを抱える環境に対しては、その期間は締め切りのようには機能せず、待ち行列のように振る舞い始めます。

待ち行列には順番があります。誰かがそれを決めます。多くの組織では、その順序付けは非公式に、パッチサイクルを運用する人によって行われ、通常はCVSSスコア、場合によっては最も多くのチケットを発生させたシステムによって決まります。それが記録されることはまれで、見直されることもまれで、パッチpolicyに署名している本人が決めることはほとんどありません。

今月明らかになったのは、そのギャップです。露出期間は、実際にはあなたの入念さだけで決まるものではありません。それは、あなたの入念さをリリースの規模で割ったものにすぎず、その2つの数値のうちあなたのものは片方だけです。

メールクライアントのpreview-pane-triggerableなバグは、その待ち行列の前方に置かれるべきです。なぜなら、ユーザー操作による遅延がなく、設計上、見知らぬ相手からのメールを読み込むソフトウェアに存在するからです。今月それがそこに入ったかどうかは答えられる問いであり、その答えは総数よりもはるかに有用です。

これは何ではないか

率直な注意点を3つ挙げます。議論のほうに助けは必要ありません。

過去最多のCVE件数は、どれだけ多くの人が調べているかの指標でもあります。より多くの研究者、より優れたfuzzing、そして開示に報いるベンダープログラムは、同じ月に基盤ソフトウェアが悪化していなくても、その数を押し上げます。記録は事実ですが、きれいなリスクシグナルではありません。

preview paneをオフにすることは実際の緩和策であり、実際のコストも伴います。1日に100件のメッセージを仕分ける人はそれを常用しており、そこまで作業を遅くする制御は、正式かどうかにかかわらず、四半期以内に再びオンにされます。

パッチ適用は、パッチ済みの脆弱性に対する正しい答えであり続けます。ここでは、それを減らすべきだとは主張していません。議論しているのは、リリース規模が他人の決定であるとき、固定の期間が何を約束できるのかということです。

問う価値のある質問

あなたの名前がpatch policyに載っているなら、今週問うべきなのは、期限内に収まったかどうかではありません。ほとんどのチームは収まっていましたし、これから収まるでしょう。

どの項目が待ち行列の前方に送られたのか、誰がそれを決めたのか、そして誰も何も開かなくても発火するバグがその中に含まれていたのかを尋ねてください。誰も答えられないなら、その順序付けこそが制御であり、現時点では文書化されていません。

オーストラリアのパッチ適用期限については、公開されている文脈での詳細をAustralia compliance pageでご覧ください。MASおよびCSAの期待事項については、Singapore compliance pageをご覧ください。