預覽窗格就是攻擊面

Microsoft 於 2026 年 9 月 8 日發布了有紀錄以來最大的一批安全修補。標題數字取決於誰在統計：Tenable 算出 964 個 CVE，Zero Day Initiative 算出 972 個，其他來源甚至更高，因為外部項目與 Chromium 項目的歸類方式不同。總量大約是 8 月的兩倍，約有一百個被評為重大，其中兩個已在野外遭到利用。

真正會改變局勢的數字，比那些都小得多。

根據 Zero Day Initiative 對當月的檢視，該版本中 22 個重大 Microsoft Office 修補程式有 12 個可從 Preview Pane 或 Reading Pane 觸發。其中最嚴重的三個 CVSS 分數皆為 9.8：Windows Graphics Component 中的 CVE-2026-77493、Word 中的 CVE-2026-78510，以及 Outlook 的 Reading Pane 中的 CVE-2026-78509。

沒有任何內容被開啟。沒有出現巨集提示。訊息送達後，用戶端會繪製附件預覽，而程式碼就執行了。

渲染就是剖析

預覽窗格是一項便利功能，但它的工作並不輕鬆。要讓你看到檔案內容，它必須先把檔案拆解：解壓縮容器、走訪記錄結構、解析內嵌字型與影像、執行版面配置、繪製結果。這些步驟中的每一步，都是程式碼在讀取攻擊者提供的位元組並對其做出判斷。

這就是整個攻擊面，而這也是沒有人會把它視為一個動作的部分。讀取檔案感覺上是被動的。其實不是。格式錯誤的長度欄位、刻意構造的字型表、圖形元件中的 use-after-free：這些都不需要文件被信任，只需要它被繪製出來。

這就是為什麼「支援的檔案類型」這個說法值得小心看待。用戶端能預覽的每一種格式，都是它所暴露出的解析器；而用戶端越是熱心地在未被要求時就把內容顯示給你看，在任何判斷做出之前，可觸及的攻擊面就越大。

不在流程中的決策

幾乎所有流通中的使用者指引，都是圍繞著「開啟」這個動作建立的。不要開啟來自你不認識寄件者的附件。在開啟之前先檢查地址。點擊之前先將滑鼠停留在連結上。網路釣魚模擬正是在衡量這一點：誰點擊了、誰開啟了、誰回報了。

這一切都針對人類判斷的某個時刻。而本月 12 個重大 Office 漏洞，位於那個時刻之前。

這並不是在主張資安意識訓練毫無價值。它能攔下憑證釣魚、商務電子郵件詐騙、看起來不像發票的發票，而這些也正是實際送達內容中的大宗。這是在主張，資安意識訓練不能成為檔案攜帶型程式碼執行的控制措施，因為在程式碼執行的那一刻，使用者根本不在流程中。一個回報點擊率表現優異的方案，對這類錯誤其實什麼也沒說，因為它衡量的是一個從未出現在路徑上的決策。

對預覽窗格的誠實解讀是：它把信任邊界往前推了，早於人們的心智模型。邊界不是使用者的決策，而是組織接受的檔案落到某個用戶端會將其渲染的位置的那一刻。

監管機構已經把這套軟體點名了

這些規則背後的直覺是對的，而且值得明說。

澳洲信號局強化了 Essential Eight 的修補時限，針對那些依其原話會經常與來自網際網路的不受信任內容互動的應用程式：辦公生產力套件、網頁瀏覽器及其擴充功能、電子郵件用戶端、PDF 軟體與安全產品。該時限從一個月縮短為兩週。這份清單正好就是本月發布版本衝擊最嚴重的軟體，而所述理由也正是最恰當的理由。

新加坡的要求則從不同角度朝同一方向前進。MAS Technology Risk Management Guidelines 要求金融機構建立修補管理流程，依嚴重性評估並在明確時限內部署修正，而不是等到方便時才做；CSA 的 Cybersecurity Codes of Practice 對關鍵資訊基礎設施也有同等要求。這些都不算特別罕見。如今，該地區幾乎每一套框架都會規定某種修補窗口。

針對可變發布的固定窗口

這裡有一部分是不會被寫下來的。

修補窗口是對你流程的一種承諾。它說明一旦有修正可用，你會多快採取行動。它沒有說明一次會湧入多少，而第二個數字完全由別人決定。

兩週對一般的一個月來說，是合理的承諾。可若面對的是一個月內發布超過 960 個修正、其中約有一百個屬於重大，且橫跨有變更窗口、測試週期、正在休假的應用程式負責人，以及少數無法在上班時間重新啟動的系統的環境，這個窗口就不再像截止期限，而開始像排隊。

排隊有順序。有人會決定它。在多數組織裡，這種排序都是非正式進行的，由執行修補週期的人來決定，通常依 CVSS 分數，有時則看是哪個系統產生了最吵的工單。這種排序很少被記錄、很少被審查，而且幾乎從來不是由在 patch policy 上簽名的人來決定。

這就是本月所揭露的落差。暴露窗口其實不完全取決於你的勤勉程度。它取決於你的勤勉程度除以發布規模，而這兩個數字裡，只有一個是你能控制的。

一個可由預覽窗格觸發的郵件用戶端漏洞，理應排在那個隊列的前面，因為它不需要任何使用者互動來拖慢攻擊，而且它本來就位於會設計上讀取陌生人郵件的軟體中。它這個月是否真的排到前面，是一個可以回答的問題，而回答它比只看總數更有用。

這不是什麼

三個誠實的但書，因為這個論點不需要額外幫忙。

創紀錄的 CVE 數量，部分反映的是有多少人在觀察。更多研究人員、更好的 fuzzing，以及獎勵揭露的供應商計畫，都會在底層軟體沒有在同一個月變得更糟的情況下，把數字往上推。這個紀錄是真實的，但它不是一個乾淨的風險訊號。

關閉預覽窗格確實是一種緩解措施，而且有實際成本。每天要分流一百封訊息的人會持續使用它，而一個會讓他們慢下來那麼多的控制措施，通常會在一季內被重新打開，無論是正式還是非正式地。

對已修補的漏洞來說，修補仍然是正確答案。這裡沒有任何內容主張少做這件事。這個論點在談的是：當發布規模是別人的決定時，固定窗口能承諾什麼。

值得提出的問題

如果你的名字寫在 patch policy 上，那麼這週該問的不是你是否在窗口內。大多數團隊都在，或將會在。

要問的是哪些項目被排到隊列前端、是誰做的決定，以及那些在沒有人打開任何東西時就會觸發的漏洞是否也在其中。如果沒有人能回答，那麼排序本身就是控制措施，而它目前沒有文件記載。

關於澳洲在其已發布脈絡中的修補時限，請參閱我們的 Australia compliance page；關於 MAS 與 CSA 的要求，請參閱 Singapore compliance page。