預覽窗格就是攻擊面

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 漏洞都位於這個時刻之前。

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

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

監管機構早已將這套軟體點名

規則背後的直覺是對的，這一點值得說明。

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

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

固定窗口對上可變版本

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

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

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

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

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

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

這不是什麼

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

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

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

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

值得問的問題

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

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

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