Updated 06:44
FortiMail CVE-2026-104286 is exploited through IBE, and the first fix was turning IBE off
CVE-2026-104286 (CVSS 9.8) affects FortiMail 7.2 through 8.0.1; CISA gave federal agencies three days.
Fortinet published advisory FG-IR-26-175 for FortiMail on Thursday, October 1, 2026, and marked the flaw as already exploited. CISA added it to its Known Exploited Vulnerabilities catalog the same day. On that first day the advisory's main instruction was a workaround: turn off the feature the bug lives in. The fixed firmware releases came over the next two days.
What Fortinet disclosed
The advisory describes CVE-2026-104286 as a combination of two weaknesses:
An Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') [CWE-22] and Improper Neutralization of NULL Byte or NULL Character [CWE-158] vulnerability may allow an unauthenticated attacker to write arbitrary files on the underlying system via crafted HTTP or HTTPS requests.
Fortinet PSIRT, FG-IR-26-175
Fortinet rates it CVSS v3 9.8, lists the impact as "Execute unauthorized code or commands," and names the GUI as the affected component. The advisory says the flaw was "Internally discovered and reported by Gwendal Guégniaud of Fortinet Product Security team," and it says plainly: "This has been reported to be exploited in the wild, customers are urged to apply the workaround below."
Affected versions and the advisory's fix path:
| Branch | Affected | Solution | |---|---|---| | 8.0 | 8.0.0 through 8.0.1 | Upgrade to 8.0.2 or above | | 7.6 | 7.6.0 through 7.6.6 | Upgrade to 7.6.7 or above | | 7.4 | 7.4.0 through 7.4.8 | Upgrade to 7.4.9 or above | | 7.2 | 7.2.0 through 7.2.9 | Upgrade to branch 7.4 or above |
There is no fixed 7.2 build. Sites on that branch have to move to a different branch.
Workaround first, firmware later
The bug is in Identity Based Encryption (IBE), and the advisory's first remedy is to switch IBE off, either in the GUI (Encryption, then IBE, then IBE Service set to off) or from the CLI:
config system encryption ibe
set status disable
end
If you can't disable IBE, Fortinet offers two alternatives: keep the FortiMail webmail interface off the internet or limit it to a trusted private network, or, if a web application firewall sits in front of the appliance, "block POST requests to /ibe that contain '../'". The advisory also says "Virtual Patch: No".
The advisory's timeline has two entries: "2026-10-01: Initial publication" and "2026-10-05: Solution update." Fortinet's release notes show the fixed builds arriving between those dates. The FortiMail 7.6.7 notes (build 858) list their initial release on 2026-10-02, and the 8.0.2 notes (build 263) list theirs on 2026-10-03. I could not find a publication date in the 7.4.9 notes (build 630).
Neither set of release notes names CVE-2026-104286. Both have a "Common Vulnerabilities and Exposures" table that lists bug IDs against "CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')" and points readers to the PSIRT site. The table does not list CWE-158. To confirm a fix, rely on the version numbers in the advisory, not on a CVE search of the release notes.
CISA's catalog entry set a due date of 2026-10-04, three days after it was added, and marks the entry "forensicTriage": "Yes". That means federal agencies running 8.0 had about one day between the 8.0.2 release notes and the deadline. The required action covers this case: apply mitigations "in accordance with vendor instructions" or "discontinue use of the product if mitigations are unavailable."
What to look for
Fortinet published indicators of compromise along with the advisory. Patching doesn't remove an implant that is already there, so they matter:
- IP addresses: 79[.]141.169.187 and 45[.]129.0.192.
- System event logs: an unexpected root cron entry, and a configuration event recording a new archive account named
archive234withdestination[remote]andremote-ip[79.141.169.187]. - Encryption logs: an IBE decrypter
BufferExceptionreporting "Invalid Base64 Encoding at pos 0. Character=0x2a", and failed logins from a wildcard internal user (*@domain.tld).
The archive-account entry deserves the closest look. By its fields, an archive account with a remote destination is a way to copy mail off the appliance on a schedule. That reading is mine, not Fortinet's: the advisory lists the log line without explaining what the account was used for. On a mail gateway, though, any archive account you didn't create should be handled as a possible mail leak, not just a configuration oddity.
What to do
- Find out whether IBE is enabled. If you don't use it, disable it now, before anything else.
- Upgrade to 8.0.2, 7.6.7 or 7.4.9 (or later). Move off 7.2.
- Search system event logs for archive accounts and cron entries you didn't create, and check outbound traffic to the two listed IP addresses.
- If any indicator matches, treat the appliance as compromised. Upgrading will not remove what an attacker already wrote to it.
Primary sources: Fortinet PSIRT FG-IR-26-175, FortiMail 7.6.7 release notes, FortiMail 8.0.2 release notes, CISA KEV alert, October 1, 2026, CISA KEV catalog feed, read 2026-10-06.