FortiMail Critical RCE Flaw Suspected of Active Exploitation: Patching and Detection Checklist for Hong Kong Organisations and MSPs
Fortinet has issued a security advisory warning of a critical remote code execution vulnerability (CVE-2026-104286) affecting its FortiMail email gateway product. According to a report by BleepingComputer on 2 October 2026, the flaw has already been exploited by attackers in zero-day attacks, with the goal of executing unauthorised code or commands on affected devices.
Readers should note that Fortinet's official advisory explicitly warns of unauthorised code execution risk but does not itself formally designate the flaw as a "zero-day"; the "actively exploited" claim currently originates from third-party reporting and remains subject to confirmation against Fortinet's PSIRT advisory.
FortiMail is typically deployed at the internet perimeter and handles all outbound email correspondence. Once compromised, an organisation's entire email infrastructure could potentially be taken over. The urgency of this incident therefore stems primarily from the reported fact that exploitation has occurred — not from the vulnerability's severity rating alone.
The checklist below represents practical guidance compiled by our editorial team. It is supplementary in nature and does not replace Fortinet's official PSIRT advisory. All remediation decisions should be based on Fortinet's latest advisory as the sole authority.
Step 1: Run an Affected-Version Diagnosis
- Log into the FortiMail console and confirm the currently deployed firmware version (CLI:
get system status, or via the System Information page on the management interface). - Cross-reference the version against the "affected versions" and "patched versions" ranges listed in Fortinet's advisory. Advisory version ranges are sometimes revised, so you must re-verify against the official advisory on the day of your change window.
- Classify and register the results as: Patched / Unpatched / Version Not Applicable, recording device identifiers, locations, and responsible owners.
- Unpatched devices should all be treated as emergency-patching targets, not queued into the next routine maintenance window.
Step 2: Distinguish FortiMail from FortiGate
Coverage in the media and community discussions sometimes conflates the two products. Our editorial team's reminder:
- FortiMail is the email security/gateway product — the target of this vulnerability.
- FortiGate is the firewall/UTM product — a different scenario, and the fact that a FortiGate is running the latest version does not mean FortiMail is similarly protected.
- Your asset inventory should list both product lines separately, to avoid the misjudgement that "we've patched the firewall, so we're done."
Step 3: Confirm Scoring and Advisory Information
CVSS scores, full attack vectors, and affected-version ranges should be verified directly against Fortinet's official advisory rather than relying on secondary reporting. It is also recommended to query the CISA Known Exploited Vulnerabilities (KEV) Catalogue to determine whether CVE-2026-104286 has been listed in KEV (and any remediation deadlines applicable to government or military organisations). Record the verified results in your patch register.
Step 4: Detect Signs of Existing Compromise
- Review FortiMail and surrounding logs, watching for anomalous management-interface logins, unusual command execution, and unauthorised configuration changes in recent activity.
- Compare recent backups against current configurations to check for signs of persistence or backdoor-like settings.
- Escalate any findings through your incident response process and preserve evidence for subsequent forensic analysis.
Step 5: MSPs — Exposure Scales Multiplicatively
- If you manage FortiMail across multiple customers on a unified version, a single unpatched firmware version may represent simultaneous exposure across many customers.
- Establish a portfolio-wide patch register to inventory all customer devices in a single pass.
- Review security patching clauses within service level agreements (SLAs), confirming the activation mechanism and communication process for emergency patching.
- Deploy unified versions to reduce the risk associated with each individual change.
Step 6: The Last Line of Defence
Even after patching is complete, you should still evaluate defence-in-depth measures such as restricting management-interface access, enabling multi-factor authentication, and strengthening network segmentation. An email gateway occupies a critically important position and is not suitable as a single point of defence.
Editorial Note: This article is a practical checklist. All CVE scores, affected versions, and KEV status are governed by Fortinet's PSIRT advisory. The claim that the flaw has been "exploited in zero-day attacks" is currently attributed to BleepingComputer's reporting; Fortinet's official advisory has not formally designated it as a zero-day, and editorial staff will publish any updates if this assessment changes. Once a vulnerability is listed in KEV, the remediation window is often only a few weeks long, making early version verification the most prudent course of action.
FortiMail 重大 RCE 漏洞疑遭實際利用：香港企業與服務供應商的修補及偵測清單
Fortinet 已發出安全公告，警告其 FortiMail 電郵閘道產品存在一項重大遠端程式碼執行漏洞（CVE-2026-104286）。據 BleepingComputer 於 2026 年 10 月 2 日報道，該漏洞已被攻擊者在零日攻擊中實際利用，目的是在受影響的裝置上執行未經授權的代碼或指令。
讀者應留意，Fortinet 官方公告明確警告了未經授權的代碼執行風險，但本身並未正式將該漏洞標示為「零日」；「已被實際利用」的說法目前來自第三方報道，尚需與 Fortinet PSIRT 公告對照核實。
FortiMail 通常部署於互聯網邊界，處理所有對外郵件往來。一旦失守，整個組織的電郵基建可能被接管。因此，本次事件的急迫性主要來自「已發生實際利用」這一報道中的事實，而不僅僅是漏洞評級本身。
以下清單為本報編輯部整理的實務指引，僅屬補充性質，並不能取代 Fortinet 官方 PSIRT 公告。所有修補決定，都應以 Fortinet 最新公告為唯一依據。
第一步：執行受影響版本診斷
- 登入 FortiMail 控制台，確認目前部署的韌體版本（CLI：
get system status，或透過管理介面的 System Information 頁面查閱）。 - 將版本與 Fortinet 公告列明的「受影響版本」及「已修補版本」範圍逐一核對。公告的版本範圍有時會作出修訂，因此必須在變更窗口當日再次根據官方公告核實。
- 將結果分類登記為：已修補 / 未修補 / 版本不適用，並記錄裝置識別編號、位置及負責人。
- 未修補的裝置，應一律列為應急修補目標，而非排入下一個例行維護窗口。
第二步：分辨 FortiMail 與 FortiGate
坊間報道及社群討論有時會混淆兩者，編輯部提醒：
- FortiMail 是電郵安全／閘道產品 —— 本次漏洞針對的對象。
- FortiGate 是防火牆／UTM 產品 —— 情況不同，不應因為 FortiGate 運行最新版本，便假設 FortiMail 亦同樣受到保護。
- 各方的資產清單應分開列出兩類產品，以避免出現「已修補防火牆便算完成」的誤判。
第三步：確認評分與公告資訊
CVSS 評分、完整攻擊向量及受影響版本範圍，應直接核對 Fortinet 官方 advisory，而非依賴二手報道。同時建議查詢 CISA Known Exploited Vulnerabilities (KEV) Catalogue，確認 CVE-2026-104286 是否已列入 KEV（以及政府或軍方機構適用的修補期限）。應將核實結果記錄於修補登記冊。
第四步：偵測既有入侵跡象
- 檢視 FortiMail 及周邊日誌，留意近期活動中出現的異常管理介面登入、異常指令執行及未經授權的配置變更。
- 將近期備份與現行配置逐一比對，排查是否存在持久化或後門式設定。
- 將任何發現按既定事件響應流程上報，並保留證據以供日後鑑識分析。
第五步：服務供應商 —— 暴露屬相乘而非相加
- 若以統一版本管理多個客戶的 FortiMail，單一未修補的韌體版本可能同時代表多個客戶的暴露。
- 建立組合層面（portfolio-wide）的修補登記冊，一次性盤點所有客戶裝置。
- 檢視服務水平協議（SLA）中的安全修補條款，確認應急修補的啟動機制及溝通流程。
- 統一版本部署，以降低每一項獨立變更所帶來的風險。
第六步：最後防線
即使修補完成，仍應評估各項深度防禦措施，例如限制管理介面存取、啟用多因素認證、加強網絡分段等。電郵閘道所處位置過於關鍵，不適合作為單一防禦點。
編輯部提示： 本文屬實務清單，所有 CVE 評分、受影響版本及 KEV 狀態，均以 Fortinet PSIRT 公告為準。關於漏洞「已在零日攻擊中遭實際利用」的說法，目前引述自 BleepingComputer 的報道；Fortinet 官方公告並未正式將其定性為零日，如該評估日後出現變更，編輯部將另行更新。相關漏洞一旦列入 KEV，修補時限往往只有數星期，及早核實版本乃是最穩妥的做法。