CRITICAL: FortiMail Zero-Day CVE-2026-104286 Exploited Before Patch

If you run FortiMail, today is not the day to catch up on your inbox. It is the day to make sure attackers have not already moved into the box that filters it.

On October 1, 2026, Fortinet published advisory FG-IR-26-175 for CVE-2026-104286, a critical path traversal flaw in FortiMail that lets an unauthenticated attacker write arbitrary files to the appliance with nothing more than crafted HTTP or HTTPS requests. Fortinet rates it 9.8 on the CVSS scale and states plainly that it "has been reported to be exploited in the wild." CISA added it to the Known Exploited Vulnerabilities catalog the same day and gave federal civilian agencies until October 4 to finish forensic triage and mitigation. That is a three-day fuse, which is about as close as CISA gets to shouting.

Here is the part that should make your stomach drop a little. There is no patch yet. Fortinet lists the fixed releases as upcoming, which means every FortiMail administrator on the planet is currently relying on a workaround while somebody else already has a working exploit. Welcome to the worst kind of zero-day.

What the Bug Actually Does

Fortinet describes CVE-2026-104286 as a combination of two weaknesses. The first is CWE-22, improper limitation of a pathname to a restricted directory, which is the formal name for good old path traversal. The second is CWE-158, improper neutralization of a NULL byte or NULL character. Put those together and you get a classic trick that never seems to die. An attacker sends a request containing a file path that climbs out of the directory it is supposed to stay in, and a NULL byte gets the software to ignore whatever suffix or extension check was supposed to keep the write safe. The server then cheerfully writes attacker-controlled content to a location of the attacker's choosing.

Arbitrary file write on a network appliance is rarely the end of the story. It is the beginning of remote code execution. If you can drop a shared library somewhere the system will load it, overwrite a binary that runs with privileges, or edit a web server configuration, you own the device. Based on the indicators Fortinet released, that is exactly what the attackers have been doing.

The flaw sits in the web-facing side of FortiMail and is tied to the Identity Based Encryption feature, which is why disabling IBE is one of the two workarounds Fortinet recommends. IBE is the piece that lets FortiMail send encrypted mail to outside recipients through a web portal, so it is also the piece many organizations deliberately expose to the internet. That is a large and inviting attack surface for a pre-authentication bug.

Fortinet credits the discovery to Gwendal Guégniaud of its own Product Security team. Internal discovery is normally good news, but in this case the timing suggests Fortinet found the bug while investigating attacks that were already underway. The company has not said when exploitation began or how many customers have been compromised, so assume the window is longer than you would like.

Affected Versions and Patch Status

Every supported FortiMail branch is in scope. FortiMail 8.0.0 through 8.0.1 is vulnerable, as are 7.6.0 through 7.6.6, 7.4.0 through 7.4.8, and 7.2.0 through 7.2.9. The fix will land in FortiMail 8.0.2, 7.6.7, and 7.4.9, but at the time of writing those builds are still listed as upcoming. Customers on the 7.2 branch are being told to migrate to the 7.4 branch or later, which in practice means waiting for 7.4.9 like everyone else and then doing a major version jump in the middle of an incident. Nobody enjoys that kind of upgrade, but it beats being the subject of a breach notification.

Nothing in the advisory limits the issue to hardware appliances, so do not assume a virtual machine in Azure or AWS is any safer than the rack unit in your server room. If it runs an affected FortiMail build and its web interface or IBE portal is reachable, it is a target.

What Exploitation Looks Like

Fortinet shipped a useful set of indicators of compromise, and they paint a clear picture of a persistent, stealthy implant rather than a smash and grab. The attackers added a shared library at /data/lib/liblog.so and created /data/etc/ld.so.preload, which forces that library to be loaded into every dynamically linked process on the system. That is a well-worn Linux rootkit technique, and it gives the attacker a hook into practically everything the appliance does, including the processes that handle mail.

They also dropped two new binaries, /data/bin/webconsole and /data/bin/mailservice, both named to blend in with legitimate components if anybody happens to glance at a directory listing. On top of that, they modified the existing /bin/smit binary, altered /data/etc/httpd.conf, and tampered with /data/migadmin.tar.gz. Modifying the web server configuration is a common way to wire in a web shell or proxy path, and tampering with the admin interface archive suggests the attackers wanted their changes to survive normal operations.

Fortinet also published two IP addresses linked to the activity, 79.141.169[.]187 and 45.129.0[.]192, along with SHA-256 hashes for the malicious and modified files. Anyone with firewall or proxy logs should search for traffic to and from those addresses going back as far as retention allows.

Why would anybody go to this much trouble for an email gateway? Because an email gateway is a gold mine. It sees every inbound and outbound message, often holds credentials for directory lookups, and sits in a trusted position at the network edge. An implant on FortiMail can read mail, harvest attachments, steal credentials, and quietly redirect or tamper with messages. For a threat actor running business email compromise or espionage, it is close to the perfect vantage point. Fortinet appliances have been a favorite target of both criminal crews and state-backed groups for years, and nothing about this campaign suggests that trend is slowing down.

What to Do Right Now

Start with the workaround, because waiting for the patch is not a plan. Fortinet's first recommendation is to disable IBE support, which you can do in the GUI or from the CLI by entering config system encryption ibe, then set status disable, then end. If your organization depends on IBE for encrypted external mail, that will hurt, and you should warn the business before you flip the switch. It will hurt a lot less than a compromised mail gateway.

The second workaround is to remove internet access to the FortiMail management interface entirely, or at minimum restrict it to a trusted private network or VPN. Frankly, if your FortiMail admin page is reachable from the open internet in 2026, this advisory is just the latest reason to fix that. Do both workarounds if you can.

Next, assume compromise until you prove otherwise. Mitigating the bug does nothing to remove an implant that is already there. Check every FortiMail appliance for the files Fortinet listed, paying special attention to /data/etc/ld.so.preload, which should not exist on a clean system. Compare file hashes against Fortinet's published values, review httpd.conf for unfamiliar directives, and look for unexpected processes named webconsole or mailservice. Search firewall, proxy, and NetFlow data for the two attacker IP addresses. If you find anything, isolate the appliance, capture forensic images before you rebuild, and rotate every credential FortiMail has touched, including LDAP bind accounts, admin passwords, and any API keys used for integrations.

Detection teams should add alerts for new or modified files under /data/bin and /data/lib, outbound connections from the FortiMail appliance to unfamiliar hosts, and HTTP requests to the appliance containing traversal sequences or encoded NULL bytes such as %00. Mail gateways rarely make outbound connections to random IP addresses, so that last signal tends to be high quality.

Finally, plan the upgrade now. When FortiMail 8.0.2, 7.6.7, and 7.4.9 drop, you want to deploy them within hours, not weeks. If you are still on 7.2, start planning the jump to the 7.4 branch today so you are not doing it from scratch under pressure. Keep an eye on the advisory page, because Fortinet will update it when the builds are released, and it may add new indicators as the investigation continues.

The Bigger Picture

This is the latest in a long line of Fortinet edge devices getting hit before customers had a chance to patch, and it will not be the last. Security appliances are attractive precisely because they are trusted, exposed, and rarely monitored with the same rigor as servers and workstations. Most organizations would notice a strange binary on a domain controller long before they would notice one on their mail gateway. Attackers know that, which is why they keep coming back.

The lesson is not that Fortinet is uniquely bad. The lesson is that every internet-facing appliance needs its management plane locked down, its logs shipped somewhere central, and its file integrity checked on a schedule. If your only defense for an edge device is "we patch it when the vendor tells us to," a zero-day with no patch exposes that strategy for what it is.

The MSP Angle

Every client running FortiMail needs a compromise assessment this week, not just a configuration change, and that is a billable incident response engagement that also proves your value to clients who think email security is a set-and-forget product. Use the moment to pitch managed edge device monitoring and a recurring external attack surface review, because a client who just learned their mail gateway admin page was on the open internet is a client ready to pay someone to make sure it never happens again.