预览窗格就是攻击面

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。 9.8

没有任何内容被打开。没有出现宏提示。消息到达，客户端为附件绘制预览，然后代码运行。

渲染就是解析

预览窗格是一项便利功能，但它承担着一项要求很高的工作。为了向你显示文件内部内容，它必须先把文件拆开：解压容器、遍历记录结构、解析嵌入字体和图像、执行布局、绘制结果。每一步都是代码在读取攻击者提供的字节并据此做出决定。

这就是整个攻击面，而这部分从来没人把它当作一个动作。读取文件感觉是被动的。其实不是。一个格式错误的长度字段、一个精心构造的字体表、图形组件中的 use-after-free：它们都不要求文档值得信任，只要求它被绘制出来。

这就是为什么“受支持的文件类型”这个说法值得谨慎对待。客户端能够预览的每一种格式，都是它所暴露的一个解析器；而客户端越是热心地在未被要求时就把内容展示给你，在任何判断发生之前，可触及的攻击面就越大。

路径中并不存在的决定

几乎所有流传的面向用户的指导，都是围绕“打开”这一动作构建的。不要打开来自你不认识的发件人的附件。打开前先检查地址。点击前先悬停查看链接。钓鱼模拟正是在衡量这一点：谁点击了，谁打开了，谁报告了。

所有这些都指向人类判断的那一刻。本月的 12 个关键 Office 漏洞都位于其上游。

这并不是说安全意识培训毫无价值。它能拦截凭证钓鱼、商业邮件欺诈、看起来不像发票的发票，而这些正是实际到达的大多数内容。这里的意思是，安全意识培训不能作为文件携带型代码执行的控制措施，因为在代码运行的那个点上，用户并不在回路中。一个报告点击率很高的项目，对这类漏洞其实什么也没说明，因为它衡量的是一个根本不在路径上的决定。

对预览窗格的诚实解读是：它把信任边界提前到了比心理模型更早的位置。边界不是用户的决定，而是组织接受的文件落到某个客户端会将其渲染出来的地方的那一刻。

监管机构已经点名了这款软件

规则背后的直觉是对的，这一点值得说明。

澳大利亚信号局将 Essential Eight 的补丁时限收紧，适用于那些按其自己的说法会经常与来自互联网的不受信任内容交互的应用程序：办公生产力套件、网页浏览器及其扩展、电子邮件客户端、PDF 软件和安全产品。该时限从一个月缩短到两周。这个清单正好就是本月发布影响最严重的软件，而给出的理由也恰恰是正确的理由。

新加坡的要求从另一个角度沿着同样的方向展开。MAS Technology Risk Management Guidelines 要求金融机构建立补丁管理流程，在规定时限内评估严重性并部署修复，而不是等到方便时再做；CSA 的 Cybersecurity Codes of Practice 对关键基础设施也提出了同等要求。这两者都不罕见。如今，地区内几乎每个框架都会规定某种补丁窗口。

针对可变发布的固定窗口

这里有一部分内容并不会被写下来。

补丁窗口是对你流程的一种承诺。它说明一旦有修复可用，你会多快采取行动。它并没有说明一次会到来多少，而第二个数字完全由别人决定。

两周对于普通的一个月来说，是一个合理的承诺。可面对这样一个月：发布了超过 960 个修复，其中大约一百个是关键级，且覆盖一个拥有变更窗口、测试周期、休假的应用负责人，以及少数无法在工作时间重启的系统的环境时，这个窗口就不再像截止日期，而开始像队列。

队列是有顺序的。有人会决定这个顺序。在大多数组织里，这种排序都是非正式完成的，由负责补丁周期的人来定，通常按 CVSS 分数，有时则按哪个系统生成了最吵的工单。它很少被记录，很少被审查，而且几乎从来不是由在补丁 policy 上签字的人来决定。

这就是本月暴露出来的差距。暴露窗口其实并不是你勤勉程度的函数。它是你的勤勉程度除以发布规模的函数，而这两个数字里只有一个是你能控制的。

一个可由预览窗格触发的邮件客户端漏洞，理应排在那个队列的前列，因为它不需要用户交互来拖慢利用过程，而且它本来就位于一种按设计会读取陌生人邮件的软件中。它这个月是否真的排到了那里，是一个可以回答的问题，而回答这个问题比总数更有价值。

这不是在说什么

三个诚实的说明，因为这个论点并不需要额外帮忙。

创纪录的 CVE 数量，部分反映的是有多少人在关注。更多研究人员、更好的 fuzzing，以及奖励披露的厂商项目，都会在同一个月里把数字推高，而底层软件未必变得更糟。这个纪录是真实的，但它并不是一个干净的风险信号。

关闭预览窗格确实是一种缓解措施，而且代价也确实存在。每天要分拣一百封消息的人会持续使用它，而一个会让他们慢下这么多的控制措施，通常会在一个季度内被重新打开，无论是正式还是非正式地。

对已修补漏洞进行补丁修复，仍然是正确答案。这里并不是在主张少做这件事。这里的论点在于：当发布规模是别人决定的时候，固定窗口究竟能承诺什么。

值得提出的问题

如果你的名字写在补丁 policy 上，那么这周该问的不是你是否在窗口内。大多数团队都在，或者会在。

要问的是：哪些项目被排到了队列前面，是谁决定的，以及那些无需任何人打开任何东西就会触发的漏洞是否也在其中。如果没人能回答，那么排序本身就是控制措施，而它目前没有文档记录。

关于澳大利亚在其已发布背景下的补丁时限，请参阅我们的Australia compliance page；关于 MAS 和 CSA 的要求，请参阅Singapore compliance page。