FortiMail Zero-Day Gives Attackers Unauthenticated File Writes on the Mail Gateway

Fortinet published advisory FG-IR-26-175 on 1 October for CVE-2026-104286, a critical vulnerability in FortiMail rated 9.8 that is already being exploited. A path traversal combined with improper handling of null bytes lets an unauthenticated attacker write arbitrary files to the appliance with crafted HTTP or HTTPS requests. CISA added it to the Known Exploited Vulnerabilities catalogue the same day and gave federal civilian agencies until 4 October to act. Fortinet credits the discovery to Gwendal Guégniaud of its own product security team.

Affected releases 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. The fixes are 8.0.2, 7.6.7 and 7.4.9. There is no fix for the 7.2 branch, so those customers have to move to 7.4 or later. Some early coverage, including Help Net Security's, reported that fixed builds were not yet available when the advisory went out, so the workarounds matter in practice.

Why a file write is enough

Arbitrary file write on an appliance usually leads to code execution and persistence, and the published indicators suggest that is what happened. According to The Hacker News, Fortinet's indicators include a new shared library at /data/lib/liblog.so, a new /data/etc/ld.so.preload, and modifications to /bin/smit and /data/etc/httpd.conf, plus two source IPs, 79.141.169[.]187 and 45.129.0[.]192. A dropped library plus changes to a system binary and the web server config looks like an implant designed to load with the appliance's own services. That is a working assumption from the file list, not something Fortinet has spelled out.

A mail gateway is an especially bad place for this. It sees every message going in and out, often including password resets and invoices. It is trusted by downstream mail servers, and it is exactly the kind of device whose integrity nobody checks from the inside.

What to do

1. Check before you patch. Look for the files and IPs above in the appliance's file system and logs. Upgrading the firmware may not remove an implant that has already changed config and binaries. If you find indicators, plan a clean rebuild and restore a known-good configuration, and do not trust an in-place upgrade.
2. Apply the workarounds now if you cannot upgrade. Fortinet's advisory lists three: disable the Identity-Based Encryption (IBE) feature, restrict webmail access to trusted networks, and use a WAF to block POST requests containing ../ to the /ibe endpoint.
3. Upgrade to 8.0.2, 7.6.7 or 7.4.9 as soon as the builds are available to you. If you are on 7.2, plan the branch migration now.
4. Rotate what the box held. If it was compromised, treat any credentials configured on it (LDAP binds, relay credentials, admin accounts) as exposed.

The recurring question

The workarounds show where the exposure is. IBE lets external recipients pick up encrypted messages through a web portal, so it has to face the internet, and that makes it pre-authentication attack surface on a security appliance. Any team running it should know whether they actually use it, and if they do not, it should already be off.

Edge appliances, including VPNs, firewalls and mail gateways, have been a favourite initial-access target for years because they sit on the perimeter, run old code with high privileges, and seldom have endpoint monitoring. Fortinet did well to find this internally and say so plainly. Still, the fixes lagged the disclosure for some customers. That leaves defenders where they usually are with these devices: disabling features and hunting for implants while they wait for a firmware build.

---

Sources

• Fortinet PSIRT — FG-IR-26-175: FortiMail path traversal and null byte injection
• Help Net Security — Critical FortiMail zero-day exploited in the wild (CVE-2026-104286)
• The Hacker News — Critical FortiMail zero-day flaw exploited in attacks