Fortinet FortiMail Zero-Day (CVE-2026-104286) Lets Unauthenticated Attackers Write Files and Take Over Appliances

A path-traversal and NULL-byte handling flaw lets an unauthenticated attacker write arbitrary files on affected FortiMail systems. Fortinet confirms exploitation in the wild.

Fortinet has disclosed a critical, actively exploited FortiMail vulnerability. CVE-2026-104286, rated 9.8, combines path traversal with improper NULL-byte handling and can let an unauthenticated attacker write arbitrary files through crafted HTTP or HTTPS requests. Fortinet marks the issue as exploited in the wild, and CISA added it to the Known Exploited Vulnerabilities catalog.

A file-write with no authentication gate

FortiMail is a mail security gateway that sits on the internet-facing edge of corporate mail infrastructure — the kind of box you point in at attackers. The flaw lives in the HTTP/HTTPS request-handling path. When FortiMail builds the path for an operation, it assembles the value from a request field without properly neutralizing a NUL (\0) byte. A NUL byte tells the C string where a path ends. So an attacker can make the appliance stop reading the path exactly where they want it to — and continue writing whatever follows into an arbitrary location on disk.

An arbitrary file write on a security appliance can be chained into code execution or persistence if an attacker reaches a location consumed by a privileged service. The public advisory establishes the write primitive and exploitation status; defenders should not assume that one particular shell-script path is the only post-exploitation route.

"The attacker didn't need a password, a session, or even a real email — just a request that carried the right invisible byte."

What's affected, and who should worry

Fortinet lists four affected ranges: 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 fixed targets are 8.0.2, 7.6.7, and 7.4.9; operators on 7.2 must migrate to a supported fixed branch. Exposure depends on the vulnerable HTTP or HTTPS interface being reachable.

That is what makes the CISA listing notable. The U.S. federal agency has cataloged the CVE as "actively exploited," which is a signal that threat actors are already out in the field using it, not that it is a theoretical risk. In a follow-up note, CISA also confirmed it was observed in the wild and set a remedial deadline for FCEB agencies — the usual marker that a real, observable intrusion is underway.

The patch split, and the version you can't easily leave

The current 8.0 line is fixed in 8.0.2, the 7.6 line in 7.6.7, and the 7.4 line in 7.4.9. The 7.2 branch has no in-place fixed release, so those operators must follow Fortinet’s supported migration path to a fixed 7.4-or-later build. Checking the exact destination matters: moving to an older 7.4 build would remain vulnerable.

Older FortiMail branches are where long-lived mail appliances tend to park, because mail gateways are the one box you do not want to bounce mid-contract every time a vendor ships a feature release. If you are sitting on a 7.2-era device, the upgrade is not a patch — it is a migration. That is the difference between a maintenance window and a project, and it is precisely why an in-the-wild exploit on that branch gets CISA attention: the affected fleet is stuck in the exact version range, for the exact reason, that makes it slow to move.

"If the fix isn't a patch but a migration, the gap between disclosure and a clean fleet is months — and that gap is where the exploitation happens."

Why this specific bug lands so hard

Path traversal and NULL-byte injection are old tricks. What makes this one dangerous is the combination of three properties at once: no authentication, an internet-exposed service, and a sink that writes to disk by default. Most traversal bugs hit a read path — you exfiltrate what's already there. This one hits a write path on a box that is already the network's front door. The intersection is exactly where a persistent, unattributable foothold is easiest to maintain.

What this means for you

If you run an affected FortiMail build, preserve relevant evidence, review Fortinet’s current indicators of compromise, and upgrade promptly. Until that is possible, follow the vendor’s documented mitigations, including disabling IBE where operationally acceptable or restricting the affected web interface to trusted networks. Exposure alone is not proof of compromise, and a clean indicator sweep is not proof that no compromise occurred.

How to check your exposure

Start with the exact version and interface exposure. If you are in one of the affected ranges, compare the appliance with Fortinet’s latest indicators and remediation guidance, then move to 8.0.2, 7.6.7, 7.4.9, or an appropriate fixed migration target. FortiMail Cloud was remediated by Fortinet; self-managed appliances require operator action.

Second, check what is now on disk. A file-write exploit is best verified by looking at the filesystem: unexpected scripts in the mail service's execution path, service definitions that reference paths the vendor never shipped, cron jobs or daemon configs that point at attacker-controlled locations. Third, check outbound: an internet-facing mail gateway that is not suddenly talking to new external hosts is the expected state, and a deviation is the anomaly you want to flag. If you cannot do that, pull the box offline — a zero-day that is actively exploited is not the kind of window you sit in while you investigate it in place.