预览窗格就是攻击面

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's Cybersecurity Codes of Practice 对关键基础设施也提出了同等要求。这两者都不罕见。该地区几乎每个框架现在都规定了某种补丁窗口。

针对可变发布的固定窗口

这里有一部分没有被写下来。

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

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

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

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

一个可通过 preview-pane 触发的邮件客户端漏洞，理应排在那个队列的前面，因为它不需要用户交互来拖慢利用过程，而且它本来就运行在会读取陌生人邮件的软件中。它本月是否排到了那里，是一个可以回答的问题，而回答这个问题比总数更有用。

这不是什么

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

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

关闭 preview pane 确实是一种缓解措施，而且也有真实成本。每天要分拣一百封消息的人会持续使用它，而一个会让他们慢这么多的控制措施，往往会在一个季度内被重新打开，无论是正式还是非正式地。

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

值得问的问题

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

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

关于 Australia 的补丁时限及其发布背景，请参阅我们的 Australia compliance page；关于 MAS 和 CSA 的要求，请参阅 Singapore compliance page。