Attackers Are Exploiting an Unpatched FortiMail Flaw, and CISA Wants Agencies to Act by October 4
Fortinet says attackers are exploiting CVE-2026-104286, a critical unauthenticated file-write flaw in FortiMail, and the fixed releases are still upcoming, so CISA’s October 4 deadline rests on a...
Fortinet says a critical flaw in FortiMail, its email security gateway, has been reported as exploited in the wild, and none of the fixed releases it has named exists yet. The bug, CVE-2026-104286, can let an unauthenticated attacker write arbitrary files to the appliance through crafted HTTP or HTTPS requests. Fortinet published advisory FG-IR-26-175 on Thursday, October 1, and the Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities (KEV) catalog the same day, giving federal civilian agencies until Sunday, October 4, to act.
Table Of Content
With no fixed release to install, the required action comes down to Fortinet’s workaround and a forensic check for signs that an appliance was already compromised.
What Fortinet has confirmed
Fortinet describes a path traversal weakness (CWE-22) combined with improper neutralization of a NULL byte (CWE-158) in the appliance’s GUI component. It rates the flaw Critical, scores it 9.8 on CVSS 3.1, lists the impact as “execute unauthorized code or commands,” and marks it as known to be exploited. The advisory credits Gwendal Guégniaud of Fortinet’s Product Security team with finding the bug internally, and it notes that no virtual patch is available.
The NVD record carries Fortinet’s 9.8 as a secondary score (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) and was still marked “Awaiting Analysis” when this was written. Decision-point data that CISA attached to the record rates exploitation as active, the flaw as automatable and its technical impact as total.
The advisory’s table of affected versions leaves little room to maneuver:
| FortiMail branch | Affected builds | Fortinet’s listed solution |
|---|---|---|
| 8.0 | 8.0.0 through 8.0.1 | Upgrade to upcoming 8.0.2 or above |
| 7.6 | 7.6.0 through 7.6.6 | Upgrade to upcoming 7.6.7 or above |
| 7.4 | 7.4.0 through 7.4.8 | Upgrade to upcoming 7.4.9 or above |
| 7.2 | 7.2.0 through 7.2.9 | Upgrade to branch 7.4 or above |
On Fortinet’s own table, no released build is listed as fixed. The 7.2 row points customers at the 7.4 branch, yet every 7.4 build up to 7.4.8 is affected, and the fixed versions carry no date: SecurityWeek notes that Fortinet “has not provided a release timeline.”
The workaround, and what it costs
Fortinet offers two interim measures. The first is to disable support for IBE, FortiMail’s identity-based encryption feature, from the command line:
config system encryption ibe
set status disable
end
The second is to block internet access to the management interface or limit it to a trusted private network. The advisory presents the two as alternatives and urges customers to apply the workaround because the flaw has been reported as exploited in the wild.
Turning IBE off is not free for every customer. Fortinet’s documentation describes IBE as the way FortiMail sends secured email to recipients who need no certificate or special software: a notification message points them to FortiMail, where a first-time recipient “must follow the instructions and links to register on FortiMail before reading email.” External IBE users, the same page says, “can only access their secure messages via the link in the IBE notification email.” Organizations that rely on that service for outbound mail have to weigh disabling it against restricting the management interface. The advisory does not describe the exploit request. watchTowr’s FAQ reads the choice of workaround as “suggesting the vulnerable code path runs through it,” an inference rather than something Fortinet states, and one of the logged indicators described below is an IBE decryption error.
What the indicators of compromise show
Fortinet published file hashes, two IP addresses and sample log entries. It lists these files as added: /data/lib/liblog.so, /data/bin/webconsole, /data/bin/mailservice and /data/etc/ld.so.preload. It lists these as modified: /bin/smit, /data/etc/httpd.conf and /data/migadmin.tar.gz. The addresses, written in defanged form as in the advisory, are 79[.]141.169.187 and 45[.]129.0.192.
The log samples describe a cron job running as root, an admin logout, an IBE decryption error reporting “Invalid Base64 Encoding at pos 0”, a failed login by an internal user, and a command-line change that added an archive account named archive234 with a remote destination at the first of those two addresses and the remote directory /uploads.
The archive entry deserves the closest look. Fortinet’s documentation describes archive accounts as the way FortiMail stores email archives locally or on a remote FTP or SFTP server, with settings for a host address, a user name, a password and a remote directory, which are the same kinds of values visible in the logged entry. BleepingComputer says the entry “could indicate that the attacker configured the compromised FortiMail appliance to send archived data to a remote server.” Two caveats apply. The documentation says to use an archive account you select it in an archive policy or action, and the advisory’s sample entries show no such policy change, although it does not say the sample is complete. Fortinet also does not say what the entry means or how often it has been seen.
A three-day deadline with no fix to install
CISA’s catalog entry gives the required action as to “apply mitigations in accordance with vendor instructions” or “discontinue use of the product if mitigations are unavailable,” flags the entry for forensic triage, and sets a due date three days after it was added. Because Fortinet has published a workaround, agencies are being asked to apply it and check for compromise rather than to pull the product. CISA’s implementation guidance says the directive’s requirement is “that an adequate forensic triage analysis is performed,” and that its suggested schedule, which begins with scoping “within first two hours of KEV addition,” is not required.
The calendar adds pressure. October 4 is a Sunday, one day after the Saturday, October 3, deadline CISA set for the Cisco Catalyst SD-WAN Manager flaw covered here on Wednesday. FortiMail is also the second email security appliance to get a three-day KEV clock in 17 days, after the Cisco Secure Email Gateway flaw was added on September 14, and Microsoft reported on September 30 that attackers had been probing a Zimbra mail server flaw since July 28. The Hacker News lists exploited bugs in Check Point, Arista VeloCloud Orchestrator, F5 BIG-IP APM, Cisco SD-WAN Manager and Citrix NetScaler among the recent cases.
For comparison, the only other entry in the catalog that names FortiMail is CVE-2025-32756, a stack-based overflow that affected FortiMail alongside other Fortinet products. CISA added it on May 14, 2025, with a three-week deadline of June 4, and Fortinet’s May 2025 advisory said it had “observed this to be exploited in the wild on FortiVoice.” Counting from the KEV data feed as released on October 1, Fortinet now has 31 entries in the catalog, eight of them added in 2026.
What is still unknown
Help Net Security reports that “Fortinet did not share details about when or where the attacks were spotted, how many systems were compromised, or who was behind them.” When BleepingComputer asked for more information about the exploitation, Fortinet pointed to the advisory and said it is “communicating with relevant government organizations, including CISA, on the content of this advisory.” The advisory marks the bug as discovered internally and as exploited, but does not say how those two facts relate in time. No fix dates have been given, and the 7.2 branch has no fix of its own.
What administrators can check now
This is a reading of Fortinet’s advisory and the public coverage, not guidance from Fortinet.
- Reduce exposure first. Apply one of the two workarounds. Neither removes anything an attacker has already written to the appliance.
- Look for the indicators. Check for the added and modified files, compare their hashes with the advisory, search logs for the two IP addresses, and review archive accounts for any you did not create, especially one with a remote destination.
- Preserve evidence. CISA’s triage guidance lists “Preserve and Collect Evidence” as its second step, so export logs and configuration before making changes where you can.
- Rotate credentials. watchTowr’s FAQ also recommends rotating administrative credentials and reviewing accounts for unauthorized changes after remediation.
- Plan for the 7.2 branch. Fortinet’s table sends those customers to 7.4 or above, and the first fixed 7.4 build, 7.4.9, is itself still upcoming.
- Watch the advisory. Its timeline section listed only the October 1 initial publication when this was written.








No Comment! Be the first one.