FortiMail 在野被利用的零日漏洞，整改期限是周日，而补丁还没发布。合规的唯一办法是关掉功能

Fortinet 于 10 月 1 日发布安全公告 FG-IR-26-175，CISA 当天就把该公告所述漏洞列入「已知被利用漏洞」（Known Exploited Vulnerabilities）目录，并为美国联邦民事机构设定了 10 月 4 日的整改期限。对一个 CVSS 9.8、无需认证即可通过 HTTP 触达的缺陷来说，这是一个跨越周末的三天时限。而真正值得写的是其中的麻烦之处：Fortinet 列为修复版本的那几个构建，在公告发布时还没有放出。处在这个期限内的组织，只能靠削减功能而不是打补丁来满足它。

公告说了什么

CVE-2026-104286 是 FortiMail 中的路径遍历漏洞，与对空字节（NULL byte）处理不当叠加在一起。按 Fortinet 的原话，攻击者可以「通过构造的 HTTP 或 HTTPS 请求在底层系统上写入任意文件」，且不需要凭据。Fortinet 明确表示该漏洞已在野被利用。公告中的发现者署名归于 Fortinet 自己的产品安全团队——也就是说，公司自己找到了这个漏洞，同时也发现它已经在被使用。

BleepingComputer 报道称，这三个版本在披露时仍未发布。Fortinet 与 CISA 都没有给出被攻陷设备的数量，也没有点名任何攻击组织。

一个靠打补丁无法满足的期限

既然没有可安装的构建，公告中的临时缓解措施就是运维人员在周日之前能做的全部：关闭 Identity-Based Encryption（IBE），并让管理界面脱离公网。这两条都是减法，而不是修复。

这件事比字面上更沉重。IBE 是 FortiMail 向没有 S/MIME 或 PGP 的收件人投递加密邮件的方式——收件人从设备自身托管的门户上取回邮件。关掉 IBE，这条投递通路就断了。对于用它传送检查报告或客户文件的医疗机构、律所和银行，这不是一次配置微调，而是周五下午一项业务流程停摆。第二条指令——限制管理界面——本是稳妥的运维惯例，但暴露在外的设备中显然有相当一部分并未遵守，否则未认证的攻击者根本触达不到这个漏洞。

所以对 10 月 4 日这个日期的诚实解读不是「周日之前打上补丁」，而是「周日之前别再可被触达」。KEV 期限衡量的是一个设备群能被改变得多快；当修复并不存在时，它衡量的就变成了一个组织愿意关掉多少功能。

更紧迫的其实是入侵指标

Fortinet 公布的不只是版本信息，还有入侵指标：被改动的系统库和二进制文件、被修改的 Web 服务器配置、一条共享对象预加载条目、cron 活动，以及命令与控制地址。当一家厂商把预加载挂钩列入指标时，它描述的不是扫描尝试，而是能跨越重启、并且视其所在位置还可能跨越升级而存续的持久化。

这会改变工作的次序。对于运行受影响版本、且 Web 界面可被触达的组织，第一个问题不是补丁何时到来，而是设备是否已经被拿下——以及日后的升级会不会把植入物一路带进一个大家随后认定「干净」的系统。指标清单应当从 Fortinet 的公告里取，它属于打补丁之前、而非之后进行的入侵排查。

边界上的一种规律

这是 2026 年里 Fortinet 客户第二次拿到一个正在被利用、而完整修复却滞后于披露的零日漏洞；CyberScoop 在 4 月报道过同样的形态，对象是 FortiClient EMS 与 CVE-2026-35616。共同点不在 Fortinet 这家具体公司，而在这个品类：安全设备终结不可信流量，运行一套 Web 管理栈，保存凭据，并且正因为一切都要经过它们而被放在边界上。两天前发布的 Bitget 根因报告，描述的入侵也正是从这一类设备开始的。

一台为检查邮件而采购的设备，在结构上就是一台面向互联网的 Web 服务器，在一个能触及组织所发每一封邮件的机器上拥有 root 权限。这个事实，业界正以一个又一个 CVE 的方式反复重新发现。

Sources: Fortinet PSIRT FG-IR-26-175, BleepingComputer, CISA Known Exploited Vulnerabilities catalog, Rapid7 vulnerability database, runZero, CyberScoop on CVE-2026-35616