Analysis · Exposure
FortiMail: a flaw exploited before the fix
From October 1 to 5, 2026, an exploited FortiMail flaw had only a workaround. A tracked risk decision, a compromise check, and the MSP angle.
By Sentrix · Published 2026-10-05
On October 1, 2026, Fortinet published bulletin FG-IR-26-175 on a FortiMail flaw that was already being exploited, and CISA added it to its Known Exploited Vulnerabilities (KEV) catalog the same day. For the first few days, the only available answer was a workaround. The scenario is not rare, and it calls for a different method than ordinary patching.
What the bulletins say
Fortinet (FG-IR-26-175, published October 1, updated October 5). CVE-2026-104286, rated 9.8 on the CVSS scale, is described as follows: "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." The bulletin adds: "This has been reported to be exploited in the wild."
Affected versions are 8.0.0 to 8.0.1, 7.6.0 to 7.6.6, 7.4.0 to 7.4.8 and 7.2.0 to 7.2.9. The updated bulletin says to upgrade to 8.0.2, 7.6.7 or 7.4.9 and above. Branch 7.2 has no fixed version: Fortinet says to move to branch 7.4 or later. In the meantime, two workarounds: disable the IBE (Identity-Based Encryption) feature, or restrict access to the webmail interface to trusted networks.
CISA (October 1). The agency added CVE-2026-104286 to the KEV catalog on the day the bulletin came out. A KEV entry means exploitation is confirmed, not merely possible.
Early analyses (October 2). Truesec wrote at the time: "Currently there are no patches available, here are the current workaround as provided by Fortinet's PSIRT." During that window, an exposed organization had two choices: turn the feature off or cut the access.
Why it matters
Most vulnerability management processes are written for one case: a fix exists, you schedule it, deploy it, verify it. FortiMail shows another, more dangerous case: the flaw is exploited, public, and there is nothing to install. If the process does not plan for it, the decision is made in a hurry, without a record, and the workaround either stays in place for months after the fix ships or disappears in a configuration change that nobody notices.
The second lesson: a mail gateway is an edge asset, exposed to the internet, just like a VPN or a firewall. It belongs in the exposure inventory with its version, its branch and the features turned on. Knowing within minutes whether IBE is enabled on your appliances is knowing whether you are exposed.
The third lesson: exploitation often comes before the bulletin. A flaw that lets anyone write files without authentication can leave traces. Applying the workaround closes the door, but says nothing about what has already come in.
What we think at Sentrix
An exploited flaw with no fix is handled in four steps:
- Know within an hour whether you are exposed. Version, branch, IBE feature, webmail interface reachable from the internet or not. That is the inventory the CTEM continuous exposure module keeps current, asset by asset, with one owner per line.
- Make the workaround a tracked risk decision. Who decided, on which appliances, on what date, until when, and the evidence that it is applied. The end date is the upgrade date, not "later".
- Look for a compromise before patching. Unexpected files, added accounts or rules, changed configuration. Keep the logs before the upgrade, which can erase traces. Our incident response service takes over if you find something.
- Upgrade as soon as the fixed version ships, then keep the workaround off only if the feature is needed, and close the risk decision. Branch 7.2 appliances must move to branch 7.4 or later.
For an MSP or an MSSP, the issue is doing it everywhere at once. The same gateway runs at several clients. The decision should be made once, applied the same day at every affected client, and recorded client by client. A single view of every client's exposure turns a night of phone calls into a work list.
The KEV catalog is the yardstick for priority: see our article on prioritizing patches with the KEV catalog and the one on the five stages of CTEM. Our vulnerability and patch management service applies the same method every day.
The next step
Write the "exploited flaw, no fix" section into your vulnerability management procedure today: who decides, how fast, how the workaround is recorded and when it is removed. Then check that your mail gateways appear in your inventory with their version. If you want to run the exercise with us, contact us.
Sources
Frequently asked questions
- Which FortiMail versions are affected by CVE-2026-104286?
- According to Fortinet's bulletin FG-IR-26-175: 8.0.0 to 8.0.1, 7.6.0 to 7.6.6, 7.4.0 to 7.4.8 and 7.2.0 to 7.2.9. The bulletin, updated on October 5, 2026, says to upgrade to 8.0.2, 7.6.7 or 7.4.9 and above. Branch 7.2 has no fixed version: Fortinet says to move to branch 7.4 or later.
- Is the workaround enough if I cannot upgrade right away?
- It reduces exposure; it does not replace the upgrade. Fortinet suggests disabling the IBE (Identity-Based Encryption) feature or restricting access to the webmail interface to trusted networks. Treat it as a temporary risk decision: who made it, on which appliances, until what date, and the evidence that it is in place. And check first that the appliance has not already been compromised.
- Why look for a compromise if I applied the workaround?
- Because the flaw lets an unauthenticated attacker write arbitrary files to the system, and it was exploited before any measure existed. A workaround applied on October 3 does not remove a file written on September 30. Look for unexpected files, accounts and configuration changes, and keep the logs before any upgrade.
Let's talk about your compliance program.
Last updated: 2026-10-05
