一项严重的 Fortinet FortiMail 漏洞已经进入不能拖延的阶段。新加坡网络安全局称，CVE-2026-104286 正遭到主动利用；攻击者无需认证，只需构造 HTTP 或 HTTPS 请求，就可能在底层系统上写入任意文件。该漏洞按 CVSS v3.1 评定为 9.8 分（满分 10 分）。

企业邮件安全网关应对遭到主动利用的漏洞的编辑插图，包含严重警报、补丁更新指示以及用于取证的网络痕迹。

这件事之所以重要，是因为 FortiMail 并不是普通应用服务器。它位于电子邮件信任边界，处理敏感邮件流量，管理接口或服务也经常暴露在互联网或其他广泛网络路径上。成功写入文件可能只是更大规模入侵的一步，但防守方不能因为完成了修补，就认定设备从未被触碰。

实际处置应当分成两条线：先立即降低暴露，再判断设备是否出现被利用的迹象。第一条线属于产品与配置工作；第二条线属于事件响应工作，即使最初证据尚不明确，也不应跳过。

CVE-2026-104286 影响什么

该漏洞被描述为未能正确限制路径名只能指向受限目录，通常称为路径遍历。简单说，请求可能让系统访问应用原本不允许访问的位置。在本案中，报告的影响是在底层 FortiMail 系统上任意写入文件。

需要特别留意以下条件：

  • 根据已发布的政府警报，攻击者不需要完成身份认证。
  • 攻击可以通过 HTTP 或 HTTPS 请求发送。
  • 后果是设备底层系统上的文件被创建或修改，而不只是网页界面显示一个无害错误。
  • 已有主动利用报告。

新加坡网络安全局列出的受影响范围包括 FortiMail 7.2.0 至 7.4.8、7.6.0 至 7.6.6，以及 8.0.0 至 8.0.1。这些范围可作为分诊起点，但不能替代对 Fortinet 当前产品公告的核对。随着调查推进，Fortinet 可能公布其他受影响分支、修正版构建或针对特定分支的操作说明。

管理员应盘点准确的运行构建版本，而不能只看采购记录中的大版本号。集群、虚拟设备、备用节点或灾难恢复镜像，可能与主系统运行不同版本。盘点范围还应包括由中央控制台管理的设备、继承而来的环境，以及被认为是内部系统但仍可通过反向代理、负载均衡器、VPN 或安全设备接收流量的设备。

为什么邮件网关需要进入事件响应流程

邮件安全设备对攻击者的价值并不局限于设备本身。它可能与邮件服务器、目录服务、管理网络、隔离区存储、日志基础设施、更新服务和身份系统之间存在网络路径。它还会看到大量通信，可能保存邮件元数据或留存内容。

文件写入漏洞并不自动证明攻击者已经取得邮箱、凭据或整个域的控制权；这些结论都需要证据。但它意味着，在完成暴露评估和记录审查前，应将该设备视为可能已经失陷的安全控制。

需要分别回答几个问题：

  1. 在存在漏洞的时期，攻击者是否能够访问该 FortiMail 实例？
  2. 是否有符合利用特征的请求抵达设备？
  3. 是否创建或修改了异常文件？
  4. 设备是否建立了异常出站连接，或发起了异常认证尝试？
  5. 是否有其他系统信任、摄取或执行了该设备产生的内容？

这种框架能让响应保持准确。它避免了两个极端：把每台存在漏洞的设备都当作已确认入侵，也避免把成功修补当作无需调查的证明。

首先要作出的运营决策

先指定一名负责人，协调网络、FortiMail 管理、身份管理和事件响应职能。这个任务不应长期停留在无人负责的队列中。如果设备保护的是高价值或受监管的邮件环境，应尽早让事件响应负责人以及相关法律或合规联系人参与。

接着确定暴露窗口。记录实例何时升级到受影响版本、何时停止服务，以及期间是否曾面向互联网。如果没有可靠历史记录，就采用该易受攻击构建版本最早可能被访问的日期，并清楚标注这是一个假设。

在进行可能抹去有用证据的变更前，先记录重建设备状态所需的事实：运行版本、系统时间与时区、在集群中的角色、网络接口、管理面暴露情况、近期管理变更，以及可用日志。遵循组织的证据处理流程。目标不是无限期冻结业务，而是保留足够上下文，以判断是否发生过可疑事件。

如果设备仍处于暴露状态，并且存在安全的隔离路径，应在维持业务实际需要的邮件流量的同时限制访问。临时管理白名单、管理面限制或受控服务路径，都可能在准备更新时降低风险。所有遏制变更都应记录时间、范围和预期副作用。

修补与缓解优先级

Fortinet 的 PSIRT 公告是固定版本和任何临时缓解措施的权威来源。应将该公告与当前 FortiMail 版本文档一起使用。不要只因为下载门户中显示了最新文件就选择某个版本；应确认它确实是相应受影响分支和部署类型的修正版构建。

操作顺序应当明确：

  • 确认哪些 FortiMail 节点和镜像受影响。
  • 获取修正版，或获取厂商规定的临时缓解措施。
  • 在安排变更期间，限制设备不必要的互联网访问。
  • 按组织恢复策略备份配置，同时将备份作为敏感数据保护。
  • 在目标节点上应用更新或临时措施。
  • 验证邮件流转、策略执行、隔离区行为、身份认证、日志记录和管理访问。
  • 对备用节点、集群组件和灾难恢复组件重复执行。
  • 记录最终构建版本，以及用于验证修复的证据。

临时缓解不等于完成修复。如果缓解措施阻断了易受攻击的请求路径，它可以降低即时暴露，但未必能处理已经被修改的文件或另一个持久化入口。在安装修正版并完成变更后检查前，应继续将设备列入调查范围。

更新前后应检查什么

具体指标和日志位置应以 Fortinet 公告及设备文档为准。防守方不应从通用路径遍历特征自行臆造本地检测规则。攻击者可以改变编码、请求路径、请求头、时间安排和投递基础设施；过于狭窄的规则还可能造成虚假的安全感。

至少应收集并审查：

  • 覆盖暴露窗口的 Web、管理、系统和事件日志。
  • 设备前方反向代理、防火墙、负载均衡器和入侵防御系统的记录。
  • 用于发现异常目的地的 DNS、代理和出口遥测。
  • 管理员账户、服务账户以及与 FortiMail 相连的集成所对应的认证记录。
  • 设备可提供的文件完整性或系统健康信息。
  • 配置变更、新账户、证书变更、策略变更和异常计划任务。
  • 集群同步记录与管理控制台记录。

重点寻找不符合正常邮件网关行为的请求，尤其是发往管理或 Web 端点的未认证请求、异常密集的请求、并非预期用户或系统的源地址，以及发生在正常维护窗口之外的活动。可疑源地址本身不能证明入侵：代理、扫描器、共享基础设施和伪造报告都可能使归因复杂化。应把事件与设备响应以及其他网络证据关联起来。

也要寻找影响，而不只是搜索利用字符串。异常出站连接、策略或路由变更、新的管理会话、证书变化、启动行为改变或无法解释的重启，可能比单条请求记录更有价值。如果日志不完整，应记录这一缺口。“没有发现证据”和“没有保留下证据”是两种不同结论。

完成修补后，再次执行相关检查。确认不再运行易受攻击版本，临时控制没有被过早移除，并确认其他节点不存在相同暴露。从面向互联网的服务视角重新审查外部暴露情况，但测试必须限定在获授权的防御流程内。

凭据与相邻系统

是否轮换凭据，应根据调查结果决定；但如果设备存储、处理或能够访问认证材料，团队应准备迅速行动。优先考虑 FortiMail 特权账户、本地管理员凭据、API 令牌、目录服务凭据、SMTP 中继密钥、监控凭据、备份凭据，以及可能在其他位置使用的证书或密钥。

不要在不了解依赖关系的情况下机械地轮换所有秘密。未经协调的重置可能中断邮件流转，也会让时间线更难解释。应先绘制凭据清单，明确哪些凭据曾存在、哪些服务接受它们，以及是否有访问证据。如果入侵可能性较高，应从可信的管理路径执行轮换，并同时监控旧凭据和新凭据是否遭到尝试使用。

检查相邻系统在同一时期是否出现认证或流量异常。该设备可能是最初目标、暂存点，也可能只是更大攻击活动中的一个组件。审查身份提供商事件、目录日志、邮件服务器认证、管理 VPN 访问，以及传输规则变更。尤其注意在 FortiMail 出现可疑事件后不久开始的活动。

组织应如何沟通

内部通知应足够具体，能够支持行动，同时不夸大事实。可用通知应说明受影响产品、CVE、已报告的主动利用、组织的暴露状态、遏制或修补时间，以及当前调查状态。还应告知员工可能发生的变化，例如短暂邮件服务中断或重新认证要求。

除非调查支持，否则不要说“所有邮件都被窃取”。在设备更新前曾暴露的情况下，也不要说“已经修补，所以没有风险”。更准确的表述通常是：设备曾存在漏洞，修复已经应用，正在审查日志和周边系统，以寻找利用证据。

如果组织承担法律、监管、合同或行业特定的报告义务，应通过事件响应流程判断是否达到通知门槛。漏洞本身并不自动构成数据泄露通知事件。已确认的未授权访问受保护信息，可能产生与“存在漏洞但未被入侵的设备”不同的义务。

一个实用的决策树

下面的顺序有助于团队避免把时间耗在标签争论上。

如果实例不受影响：记录版本证据，确认所有相关节点都已检查，并在漏洞记录中写明验证来源和日期后关闭。

如果实例受影响，但从未能被不可信网络访问：安装修正版，审查内部访问路径和日志，并记录暴露评估为何受到限制。“不面向互联网”不等于“无法访问”；必须验证网络分段和管理路径。

如果实例曾可访问，但没有利用迹象：安装修正版或应用厂商临时措施，保留相关日志，审查公告中的指标，并设定后续日期，用于重新确认检测结果和版本。

如果存在可疑请求或系统变更：将设备视为潜在事件。保全证据、限制访问、让事件响应职能介入，并在宣布事件解决前检查凭据和相连系统。

如果无法信任该设备：根据业务连续性计划，将邮件防护迁移到获批准的替代方案或受控回退路径。不要为了临时替换而把新的未修补服务暴露出去。

这种做法把事实与假设分开，也会留下可审计记录，说明组织为何选择仅修补、采取额外遏制，或启动完整调查。

不要做什么

不要为了方便紧急管理而把管理接口暴露到互联网。除非组织已明确授权、了解运营影响并制定受控计划，否则不要在生产 FortiMail 上测试利用载荷。已公开的问题足够严重，防御性验证不应演变成可以避免的服务中断。

不要把漏洞扫描器显示绿色结果作为修复完成的唯一证明。扫描器可能看到新版本，却遗漏备用设备、备用地址、反向代理路径，或遗漏设备在扫描前已经遭到入侵的证据。

在按照组织证据流程收集之前，不要删除可疑文件或日志。删除它们可能让设备看起来干净，却毁掉判断发生了什么所需的信息。如果立即遏制要求重建设备，应先记录状态，并保留可用的配置和遥测数据。

不要把 CVSS 分数当作组织实际损失的预测。9.8 分反映的是标准评分模型下的技术严重性。业务影响取决于可达性、配置、网络位置、数据访问、监控质量以及攻击者后续采取的行动。

邮件基础设施得到的更广泛教训

FortiMail 提醒我们，安全设备需要与面向公众的应用一样接受资产管理。它们往往只有在厂商宣布严重漏洞时才得到紧急关注，但设备平时所处的位置正是其价值所在。网关可能连接特权集成，拥有广泛可见性，并能访问基础软件清单中不易看出的系统。

组织应维护一份可用于事件响应的清单，记录产品系列、准确构建版本、暴露情况、负责人、管理路径、相连身份、集群成员关系、备份位置和日志保留期限。这份记录不应只是为了满足季度审计。

第二个教训是，修复与调查是两项不同的控制。更新软件会降低继续遭到利用的可能性，却不能告诉你攻击者是否在昨天利用过漏洞。成熟的响应需要同时回答：“现在还会发生吗？”以及“修复前是否已经发生过？”

第三个教训是把证据收集变成日常流程。如果代理日志只保留七天，而厂商建议检查更长的利用窗口，组织应在紧急事件发生前就知道这个限制。如果设备日志无法可靠导出，那是值得在事件结束后修复的韧性问题。

结论

CVE-2026-104286 同时具备无需认证、任意文件写入、严重性评分为 9.8，以及已报告主动利用等特征，因此应被优先处理。FortiMail 运维人员应识别受影响构建版本，限制不必要的暴露，应用 Fortinet 当前提供的修复或临时措施，并核验每一个相关节点。

随后调查存在漏洞的时期。审查厂商指标和本地遥测，保全证据，将活动与身份及网络日志关联，并在事实支持时轮换凭据。正确结论不一定是“已经入侵”，但也不能是“已经修补，所以结束”。可信的修复记录应说明暴露了什么、改变了什么、检查了什么，以及哪些事项仍不确定。

来源与延伸阅读：