Actively Exploited FortiMail Zero-Day CVE-2026-104286 Lets Unauthenticated Attackers Write Arbitrary Files — Fixed Builds Are Not Out Yet
Actively Exploited FortiMail Zero-Day CVE-2026-104286 Lets Unauthenticated Attackers Write Arbitrary Files — Fixed Builds Are Not Out Yet
CISA added a critical Fortinet FortiMail vulnerability to its Known Exploited Vulnerabilities (KEV) catalog on October 1 after reports of active exploitation, and the situation is more uncomfortable than most KEV entries: the fixed builds do not exist yet. The flaw, tracked as CVE-2026-104286 (CVSS 9.8), combines path traversal (CWE-22) with improper neutralization of NULL bytes (CWE-158), and "may allow an unauthenticated attacker to write arbitrary files on the underlying system via crafted HTTP or HTTPS requests," Fortinet said in advisory FG-IR-26-175, published October 1. The vendor's impact listing is blunt: execute unauthorized code or commands.
Affected versions are FortiMail 8.0.0-8.0.1, 7.6.0-7.6.6, 7.4.0-7.4.8, and 7.2.0-7.2.9. Fixes are listed as "upcoming" — 8.0.2, 7.6.7 and 7.4.9 — while 7.2 customers are told to upgrade to the 7.4 branch or above. In other words, every current FortiMail line is exposed and the only immediate defenses are workarounds. Fortinet acknowledged the flaw has been exploited in the wild and credited Gwendal Guégniaud of the Fortinet Product Security team with discovering it internally.
Until patches ship, Fortinet recommends disabling the IBE (Identity-Based Encryption) feature via the GUI (Encryption → IBE → IBE Service 'off') or CLI, and removing the FortiMail webmail and management interfaces from the internet or restricting them to trusted private networks. The advisory also names a third option that will feel familiar to readers of this site: "if there is a Web Application Firewall in front of FortiMail, block POST requests to /ibe that contain ../." Fortinet shared indicators of compromise including the added file /data/etc/ld.so.preload and modified /data/etc/httpd.conf and /data/migadmin.tar.gz, plus log patterns such as a root cron entry launching /bin/sh -c 'O=/migadmin...', an archive account configured to relay to remote IP 79.141.169.187, Base64 decode exceptions in the IBE decrypter, and unusual failed login bursts. Federal civilian agencies were given until October 4 to apply the patch or workarounds.
The flaw lands in the middle of a brutal season for edge appliances: Check Point, Arista VeloCloud, F5 BIG-IP, Cisco SD-WAN Manager and Citrix NetScaler flaws have all been added to KEV in recent weeks with in-the-wild exploitation, continuing the same pattern we covered with September's NetScaler zero-days. FortiMail is especially sensitive because an email security gateway is internet-facing by design — and because writes to ld.so.preload or httpd.conf are a prelude to persistent code execution, not just data theft.
What Should You Do?
- Disable IBE on every FortiMail 7.2-8.0.1 instance now, even if you don't think you use identity-based encryption — verify the setting rather than the documentation.
- Pull admin and webmail interfaces off the internet. If they must stay reachable, restrict them to trusted networks via firewall rules — this is the workaround Fortinet itself insists on.
- Add the virtual patch if a WAF fronts FortiMail: block POST requests to
/ibecontaining../— and review the rule against encoded traversal variants, not just the literal string. - Hunt for the published IoCs — the three file paths, the cron command, the archive-account relay to 79.141.169.187, and IBE Base64 exceptions — and treat any hit as full compromise: rotate credentials and rebuild from a known-good image.
The WAF Angle
This advisory is a rare case where the vendor's own mitigation is a WAF rule: Fortinet effectively told the market that inline filtering of POST requests to /ibe is a legitimate stopgap while engineered fixes are pending. A path-traversal-plus-NULL-byte payload rides a plain HTTP request, which is exactly the traffic class a WAF inspects well — but the rule as written matches the literal ../, and real attackers will URL-encode, over-long-encode, or mix separators to dodge naive string matching. If you deploy this rule, make sure normalization happens before matching, and treat it as a bridge to the real fix (disabling IBE and upgrading when builds ship), not a substitute. The bigger lesson is management-plane hygiene: the same appliance that terminates hostile SMTP for a living was also accepting web requests that could overwrite its own libraries, and the difference between "configuration interface" and "attack surface" on internet-exposed appliances is currently being priced in weeks of emergency patching.
