Exploited FortiMail Flaw Has No Patch Yet: Disable IBE Now

Fortinet says attackers are already exploiting a critical flaw in FortiMail, its email security gateway, and there is no fixed build to install yet. CVE-2026-104286 lets an unauthenticated attacker write arbitrary files on the appliance with crafted HTTP or HTTPS requests. Fortinet rates it CVSS 9.8.

Fortinet published advisory FG-IR-26-175 on 1 October 2026. CISA added the CVE to its Known Exploited Vulnerabilities catalog the same day and gave federal agencies until 4 October to act. Every supported FortiMail branch is affected, and the 7.2 branch will not get a fix at all. Until builds ship, the only protection is Fortinet's workaround: switch off Identity Based Encryption (IBE) or take the web interface off the internet.

What is affected

The advisory lists four branches. For the first three, the "fixed" versions are described as upcoming: Fortinet has not released them yet.

The 7.2 row is the hard one. Those customers must plan a branch migration. They also need the workaround in place now, because 7.4 is itself vulnerable until 7.4.9 ships.

There is a second wrinkle. The machine-readable record Fortinet filed with NVD lists FortiMail 7.0.0 through 7.0.9 among the affected builds as well, but the advisory's table does not mention 7.0. If you still run 7.0, treat the appliance as exposed and apply the workaround.

How the flaw works

Fortinet describes two weaknesses chained together: a path traversal (CWE-22) and improper neutralisation of a NULL byte (CWE-158). A crafted request steps outside the directory the web service should write to. Mishandled NULL bytes are a classic way to cut a file name short after it has passed a check. Fortinet has not published the exact request.

The vulnerable code sits behind IBE, the FortiMail feature that lets recipients outside the organisation open encrypted mail through a web portal. That is why disabling IBE is the main workaround. It is also why the exposure is wide: IBE only works if outside recipients can reach the portal, so it is internet-facing by design.

An arbitrary file write on an appliance is usually one step from code execution. The indicators Fortinet published show attackers taking that step.

What the attackers left behind

Fortinet's indicators point to implants and persistence, not just a dropped file:

• /data/etc/ld.so.preload added. It makes the system load an attacker library into every process.
• /data/lib/liblog.so added. It is a shared library, most likely the one the preload file points to.
• /bin/smit modified, and /data/bin/webconsole and /data/bin/mailservice added: replaced and new binaries.
• /data/etc/httpd.conf modified, and /data/migadmin.tar.gz modified: the web server configuration and the admin interface archive.

Fortinet also lists two source IPs, 79.141.169.187 and 45.129.0.192, and log patterns to search for:

• a cron entry running as root that starts /bin/sh -c 'O=/migadmin
• an admin logout "from (null)"
• an archive account configured with remote-ip[79.141.169.187], which would copy mail out to the attacker
• in the encryption logs, Invalid Base64 Encoding at pos 0 buffer exceptions and failed internal-user logins

The archive account is the most serious finding for most organisations. An email gateway sees every message, so a rogue archive rule is quiet, ongoing data theft.

Fortinet has not named the attacker, and nobody has published victim counts. CISA marks the entry as requiring forensic triage under BOD 26-04. That means checking for compromise as well as mitigating.

Fortinet's advisory and the CISA KEV listing landed on the same day; the fixed builds had not shipped by 2 October.

What defenders should do

1. Find every FortiMail you run, including 7.0 and 7.2 boxes and anything in a forgotten DMZ.
2. Disable IBE now if you can live without it. In the GUI, go to Encryption, then IBE, then IBE Service, and set it to off. From the CLI:

config system encryption ibe
set status disable
end

3. If IBE has to stay on, remove internet access to the FortiMail management interface, or limit it to trusted private networks. Fortinet gives this as the alternative workaround.
4. Hunt before you assume you are clean. Check for the seven files above and compare their SHA-256 hashes with the advisory. Search the logs for the two IPs, root cron jobs touching /migadmin, and archive accounts you did not create. Review all archive and forwarding rules.
5. If you find any indicator, treat the appliance as compromised. Preserve the disk and logs, rebuild from a clean image rather than deleting files, and rotate the admin credentials and any keys stored on the box. Assume archived mail was read.
6. Install 8.0.2, 7.6.7 or 7.4.9 as soon as Fortinet releases them. On 7.2, schedule the move to a fixed 7.4 or later build.

Fortinet's indicators: seven files added or modified, two IP addresses and a rogue archive account. Any hit means rebuilding the appliance.

Federal civilian agencies have until 4 October 2026 under the KEV listing. Everyone else should treat that date as a ceiling too.

Fortinet credits Gwendal Guégniaud and the Fortinet Product Security Team with the finding.

Sources

• Fortinet PSIRT, FG-IR-26-175
• NVD, CVE-2026-104286
• CISA Known Exploited Vulnerabilities catalog
• CISA BOD 26-04
• GBHackers, Fortinet FortiMail path traversal flaw actively exploited
• SecurityOnline, FortiMail CVE-2026-104286 exploited in the wild