FortiMail CVE-2026-104286: exploited unauthenticated file write

FortiMail sits at the edge of the mail flow, holding messages, archives and the credentials that connect it to the rest of the network. CVE-2026-104286 lets anyone who can reach its web interface write files onto the appliance without logging in, through the Identity-Based Encryption (IBE) feature. Fortinet rates the impact as running unauthorized code or commands.

Fortinet found the bug internally and published advisory FG-IR-26-175 on 1 October 2026 with a note that it was already exploited in the wild. CISA added it to its Known Exploited Vulnerabilities catalog the same day and gave federal agencies until 4 October. At first Fortinet pointed customers to a workaround; the advisory now lists fixed releases for three of four branches.

Who is affected

Exposure follows the IBE service and the webmail interface. Fortinet's workarounds disable IBE, take the webmail interface off the internet, or block POST requests to /ibe that carry ../ at a web application firewall. That points to the IBE web endpoint as the way in. An appliance whose webmail interface is reachable from the internet with IBE enabled is the case to fix first.

How the FortiMail file write works

Fortinet classifies the bug as path traversal (CWE-22) combined with improper handling of NULL bytes (CWE-158). In plain terms, the appliance builds a file path from part of an unauthenticated HTTP or HTTPS request without stopping ../ sequences or NULL characters. The attacker can then write a file outside the directory it was meant for.

Writing a file in the right place is often enough to run code, and Fortinet lists the impact as executing unauthorized code or commands. watchTowr told Cybersecurity Dive the bug is "trivial to exploit." Fortinet scored it 9.8 under CVSS 3.1: network attack, low complexity, no privileges, no user interaction.

Fortinet has not published the vulnerable parameter or the files an attacker targets. NVD lists only CWE-22, while Fortinet and CISA list both weaknesses.

Is it being exploited?

Yes. Fortinet's advisory reports exploitation in the wild, CISA listed it in KEV on 1 October with a due date of 4 October, and CISA's assessment records active exploitation that can be automated with total technical impact. No threat actor has been named, and Fortinet has not said how many customers were hit.

Fortinet has not said when exploitation began. One detail is worth noting with care: some log samples in Fortinet's published indicator bundle are timestamped 20 July 2026. That suggests at least one compromise more than two months before disclosure, but Fortinet has not stated a start date, and a single sample timestamp does not establish one.

Exactly when each fixed build shipped is also unconfirmed. The advisory's timeline records a solution update on 5 October but no per-build release dates, and Cybersecurity Dive reported on 2 October that Fortinet had not given a patch date.

Check your exposure

Confirm the firmware version and whether IBE is enabled, from the FortiMail CLI:

get system status
show system encryption ibe

Then check whether the webmail interface answers from the internet, using an external scan or your firewall rules, and search your syslog archive for Fortinet's indicators:

grep -rE '79\.141\.169\.187|45\.129\.0\.192|archive234|logged out from \(null\)' /path/to/fortimail-logs/

Fix it

Upgrade to 8.0.2, 7.6.7 or 7.4.9 or later. On 7.2, plan the move to the 7.4 branch. FortiMail Cloud customers need do nothing. Upgrading closes the hole but removes nothing an attacker left behind, so check for compromise as well.

If you cannot upgrade yet, Fortinet's workaround is to turn off IBE, in the GUI under Encryption, IBE, by switching IBE Service off, or in the CLI:

config system encryption ibe
    set status disable
end

Check whether you rely on IBE for encrypted mail before you change it. Fortinet's alternatives are to block internet access to the webmail interface, or allow it only from trusted private networks, or to have a WAF in front of FortiMail block POST requests to /ibe that contain ../.

Detect attempts and compromise

Fortinet published these indicators in the advisory and its STIX bundle:

• IP addresses. 79[.]141.169.187 and 45[.]129.0.192.
• Root cron job. A system event showing cron running /bin/sh as root to write a file under /migadmin/www/ named .session- plus a hex string. In the sample, the job saves the output of the CLI show command there, exposing the configuration over the web, and deletes it a day later.
• Rogue archive account. A config event adding an archive account such as archive234 that ships archives to a remote server at 79.141.169.187.
• Odd admin events. An admin logout from (null).
• IBE errors. IBE decrypter errors reporting invalid Base64 with character 0x2a, and failed-login messages for an internal user named * at your mail domain.
• Files. Eight file hashes, with notes pointing to an /etc/ld.so.preload entry loading /data/lib/liblog.so and an altered /data/etc/httpd.conf.

If any of these appear, treat the appliance as compromised: remove unknown archive accounts, cron entries and preloaded libraries, rotate credentials stored in or reachable from its configuration, and review which mail archives left the device. Consider rebuilding from known-good firmware with Fortinet support.

Beyond this patch

Mail gateways hold some of the most sensitive data in an organization and sit on the internet by design. Keep management and webmail interfaces off the public internet unless a feature truly needs them, turn off features you do not use, and forward appliance logs off the box so evidence survives a compromise.