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

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

何かを変える数は、それらすべてよりも小さいのです。

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

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

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

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

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

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

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

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

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

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

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

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

ルールの背後にある直感は正しく、そう言う価値がある。

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

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

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

ここが、文書には書かれない部分だ。

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

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

キューには順番がある。誰かがそれを決める。多くの組織では、その順序付けは非公式に行われ、パッチサイクルを回す担当者が、通常は CVSS スコア、場合によっては最も騒がしいチケットを出したシステムに基づいて決めている。記録されることはまれで、レビューされることもまれで、patch policy に署名している本人が決めることはほとんどない。

今月明らかになったのは、そのギャップだ。露出期間は、実際にはあなたの尽力の関数ではない。それは、あなたの尽力をリリースの規模で割ったものにすぎず、その 2 つの数値のうちあなたのものなのは片方だけだ。

preview-pane で引き金を引ける mail client のバグは、そのキューの前方に置かれるべきだ。なぜなら、ユーザー操作による遅延がなく、設計上、見知らぬ相手からのメールを読むソフトウェアに存在しているからだ。今月それがそこに入ったかどうかは答えられる問いであり、その答えは総数よりもはるかに有用だ。

これは何ではないか

率直な注意点を 3 つ。議論のほうに助けは要らないからだ。

過去最多の CVE 件数は、どれだけ多くの人が見ているかの指標でもある。研究者が増え、fuzzing が改善され、開示に報いる vendor プログラムがあれば、同じ月にソフトウェア自体が悪化していなくても件数は押し上げられる。その記録は本物だが、きれいなリスクシグナルではない。

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

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

問う価値のある問い

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

どの項目がキューの先頭に回されたのか、誰がそれを決めたのか、そして、何も開かなくても発火するバグがその中に含まれていたのかを問うべきだ。誰も答えられないなら、その順序付けこそが control であり、現時点では文書化されていない。

Australia のパッチ適用期間については、公開されている文脈での Australia compliance page を参照してください。MAS と CSA の期待については、Singapore compliance page を参照してください。