CVE-2026-104286

What is Fortinet FortiMail?

FortiMail is Fortinet's secure email gateway, sold as a hardware appliance, a virtual machine and a hosted service. It sits in front of an organisation's mail infrastructure and handles antispam and antivirus filtering, data loss prevention, sandboxing handoff to FortiSandbox, and message encryption. Deployments typically run in gateway mode in front of Exchange or Microsoft 365, or in server mode as the mail system itself.

Two properties make it a high-value target. First, it is by design internet-facing: an email gateway that cannot be reached from the public internet cannot receive mail. Second, it sees every message in and out of the organisation in plaintext, after decryption and before delivery. An attacker with code execution on a FortiMail appliance has a tap on the whole mail stream, plus a trusted position inside the network perimeter from which to pivot.

Overview

CVE-2026-104286 is an unauthenticated arbitrary file write in the FortiMail web interface. Fortinet describes it as a path traversal combined with improper neutralization of NULL bytes, reachable over crafted HTTP or HTTPS requests with no credentials and no user interaction. It carries a CVSS 3.1 base score of 9.8.

The vulnerable code path is the GUI component backing Identity Based Encryption (IBE), FortiMail's feature for sending encrypted mail to recipients who have no certificate or key of their own. Where IBE is enabled and the HTTP or HTTPS listener is reachable, an unauthenticated attacker can place files at a location of their choosing on the appliance filesystem. Writing to a path that the appliance later loads or executes converts the file write into remote code execution.

Fortinet marked the advisory as exploited at publication, and CISA added the CVE to the Known Exploited Vulnerabilities catalog the same day with a three-day remediation deadline, which is unusually short and reflects the BOD 26-04 risk-based schedule rather than the standard two-week window. At the time of the advisory the fixed builds were listed as upcoming rather than available, so the vendor workaround is the operative control for most defenders on day one.

Affected Versions

Secondary trackers have circulated slightly different ranges, including claims that 7.0.x is affected. Fortinet's own advisory, FG-IR-26-175, lists only the four branches above, and it is the authoritative source. Administrators on 7.0 or older should treat those builds as end of support and out of scope for a fix regardless.

Technical Details

The root cause is CWE-22, improper limitation of a pathname to a restricted directory, compounded by CWE-158, improper neutralization of NULL bytes. In plain terms, the IBE handler takes a filename or path from the request and does not properly confine it to the directory it is supposed to write into. Traversal sequences walk the write out of that directory to anywhere on the filesystem the web process can reach.

The NULL byte component is the classic truncation trick. Validation code commonly checks that a path ends with an expected extension, or that it sits under an expected prefix; a NULL byte embedded in the supplied string lets the check pass on the full value while the underlying C library call that eventually performs the write stops at the NULL and acts on a shorter, different path. The two flaws together defeat whatever filtering the handler attempted.

The attack characteristics are as bad as they get for an internet-facing appliance: no authentication, no user interaction, low complexity, network reachable, and a single request is sufficient to plant a file. No chaining with another CVE is required. The CVSS vector of AV:N/AC:L/PR:N/UI:N with High across confidentiality, integrity and availability reflects that a successful write leads to code execution as the web service.

Discovery

Fortinet credits Gwendal Guegniaud of the Fortinet Product Security team with the discovery. That is an internal finding rather than an external report, which is consistent with Fortinet shipping the advisory with indicators of compromise attached: the team appears to have worked backwards from incident data on compromised appliances rather than from a research report. Fortinet has not published a date for when exploitation was first observed, nor how long it ran before the advisory.

Exploitation Context

Both Fortinet and CISA treat exploitation as confirmed. Fortinet's advisory is unusual in publishing a full indicator set, which points to hands-on-keyboard intrusions analysed in detail rather than opportunistic scanning. The listed indicators include dropped or modified binaries and libraries under /data and /bin, among them liblog.so, smit, webconsole and mailservice; a malicious ld.so.preload, which is a well-worn Linux persistence and hooking technique that forces a chosen library into every process at load; and a modified httpd.conf. Two command-and-control addresses were published: 79.141.169.187 and 45.129.0.192.

No threat actor has been named publicly, and CISA records known ransomware campaign use as unknown. The pattern, a zero-day in an edge security appliance used to install a preload-based implant and tamper with the web server configuration, matches the espionage-oriented edge-device tradecraft seen repeatedly against Fortinet, Ivanti and Citrix gateways rather than a commodity ransomware operation. That is an inference from technique, not an attribution.

No vendor-independent exposure count for this CVE has been published. For scale, Censys counted 1,163 internet-facing FortiMail instances during an earlier Fortinet advisory, so the exposed population is in the low thousands rather than the tens of thousands. The subset actually at risk is smaller still, since the vulnerable path requires IBE to be enabled.

Remediation

1. Upgrade to FortiMail 8.0.2, 7.6.7 or 7.4.9 or above, matching your branch. Appliances on 7.2.x have no fix in that branch and must move to 7.4.9 or above. Confirm the build is available for your platform before planning the window, as the fixes were listed as upcoming when the advisory was published.
2. Until the upgrade lands, apply Fortinet's workaround and disable IBE: config system encryption ibe, then set status disable, then end. This removes the vulnerable code path. Confirm with the mail team first, as recipients outside the organisation will lose the ability to open IBE-encrypted messages.
3. Restrict the administrative and web interfaces to trusted management networks using local-in policy or trusted-host configuration. The IBE portal may need to stay public for recipients, so this limits but does not eliminate exposure; treat it as defence in depth alongside step 1 or 2.
4. Hunt for the published indicators before assuming the appliance is clean. Check /data and /bin for modified or unexpected binaries, specifically liblog.so, smit, webconsole and mailservice; check for the presence of ld.so.preload, which should not exist on a stock appliance; and diff httpd.conf against a known-good configuration. Search firewall and proxy logs for traffic to 79.141.169.187 and 45.129.0.192.
5. Review web server logs for anomalous requests to IBE endpoints, particularly requests containing traversal sequences or encoded NULL bytes, going back as far as retention allows. Exploitation predates the advisory by an unknown period.
6. If any indicator matches, treat the appliance as fully compromised. Patching does not remove an implant. Rebuild from a clean image, rotate all credentials, certificates and API keys held on the device, and preserve a forensic image first in line with CISA's Forensics Triage Requirements.
7. Federal civilian agencies had until 2026-10-04 to remediate under BOD 26-04. Everyone else should treat that same window as the realistic target given confirmed in-the-wild exploitation of an internet-facing appliance.