Fortinet FortiMail Attackers Write Files Through Its Web Interface

An attacker is already exploiting a Fortinet FortiMail flaw that lets unauthenticated web requests write arbitrary files to the appliance, according to CISA’s new Known Exploited Vulnerabilities entry. CISA’s KEV entry sets an October 4 action date. Fortinet offers two interim controls: restrict access to the management interface or disable identity-based encryption (IBE).

Fortinet’s October 1 PSIRT advisory describes the GUI flaw as path traversal coupled with improper neutralization of a NULL character. Fortinet warns: “This has been reported to be exploited in the wild, customers are urged to apply the workaround below.” Gwendal Guégniaud of Fortinet Product Security discovered and reported the flaw internally. The company lists added files, modified system files, remote addresses and system log entries that give responders more to work with than a version check alone.

FortiMail GUI requests reach disk

The affected interface accepts crafted HTTP or HTTPS requests without authentication. Path traversal lets a supplied path escape its intended directory; improper handling of a NULL character adds another failure in how that input is processed. Together, Fortinet and CISA say these weaknesses allow an arbitrary write on the underlying system. An arbitrary write can alter what the appliance runs or reads; Fortinet rates its impact as unauthorized code or command execution. Use the appliance file and system events for triage while limiting management reachability.

Fortinet’s interim alternative is to remove internet access to the management interface or allow it only from a trusted private network. Apply that restriction to the management route in the firewall and any forwarding rule while keeping mail delivery ports available.

Fortinet lists changed appliance files

Fortinet’s PSIRT indicators identify these paths and file digests. Compare the corresponding files on affected appliances with a trusted image and preserve a copy for investigation before replacing anything. “Added” and “modified” are Fortinet’s labels for the listed artifacts:

Added /data/lib/liblog.so: MD5 64c90a00c7fda4d5c7973ed64c25783a; SHA-256 8015f34dc84922b03688399d7f9fe7a00361789f7e420c7e2a2cdb23e75cef84.
Modified /bin/smit: MD5 5241738a3e9988404239e12243f6d35b; SHA-256 77324ac428bde86d351fc5fc06f6d64a6bfe737dfb2743df1d4c5ac2418a5b6a.
Added /data/bin/webconsole: MD5 ae0ea6502d3fa5f0664bceb73189eb54; SHA-256 7a6cea9f5c9e2e9994d4e3c4da73f86cf5acd05ea5d312c066c9d1dafd69ee38.
Added /data/bin/mailservice: MD5 f90fa81a5f521d785f2b2f765e3ab897; SHA-256 4000276a150a165d3c2537d1e19fb393c4de8333076a16655e28059cae82157b.
Modified /data/etc/httpd.conf: MD5 61af1c4bce1c2eebc8ff689ca5337791; SHA-256 703e97c64e61e41dc3aaba580d82bb2aa7b6a11b54ee6fb467ed5d5a3bffdef5.
Added /data/etc/ld.so.preload: MD5 8eb64f25d2a8e18e05aae058629473cf; SHA-256 8953ec7960b09f544a880b072ad4e6cfda7a8303f486251d3478dcfdfbac23b6.
Modified /data/migadmin.tar.gz: MD5 49a7156a7d043cc8f9f680579db22f86; SHA-256 d6fe51c22b91776f4c961ea58bcac5917f15d560a619d7ce726d3d51795609d3.

The advisory also lists 79[.]141[.]169[.]187 and 45[.]129[.]0[.]192. Search FortiMail configuration events for an archive account named archive234 with remote-ip[79[.]141[.]169[.]187] and remote-directory[/uploads]. Its sample system event contains ui=cron and a root shell command referencing /migadmin; a separate administrative logout event has ui=(null) and reason=unknown. Fortinet also prints an IBE decryption BufferException(2) / Invalid Base64 Encoding at pos 0 event and a failed internal-user login entry. Correlate these events with file changes and management-access history; a file match warrants incident triage rather than an ordinary patch-only ticket.

Fortinet’s upgrade targets are forthcoming

Fortinet lists 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 as affected. Its recommended releases are upcoming 8.0.2, 7.6.7 and 7.4.9, respectively; it directs 7.2 operators to move to branch 7.4 or later. Choose a remediated build on that destination branch; the listed 7.4.0–7.4.8 builds are affected. Check the latest PSIRT release table and the actual installed build before treating an upgrade as complete.

The Fortinet-assigned CVE JSON record carries older solution targets, including upcoming 8.0.1, 7.6.6 and 7.4.8, which the current PSIRT table includes among affected versions. It also includes 7.0 in its version data while the PSIRT table shown here starts at 7.2. For a 7.0 deployment, obtain Fortinet’s branch-specific answer; for the listed branches, follow the current advisory’s upgrade targets rather than the conflicting CVE solution text.

Restrict management and disable IBE

Fortinet’s other interim workaround is to disable IBE support in the FortiMail CLI:

config system encryption ibe
set status disable
end

Confirm the resulting config system encryption ibe status is disabled and test that identity-based encryption functions your organization relies on have been accounted for. Fortinet presents management-access restriction as an alternative. Where feasible, apply both controls until the supported update is installed; use an approved private management path and verify from an untrusted network that the management interface cannot be reached. CISA’s KEV entry calls for vendor mitigations and forensic triage, so keep a separate track for appliances with matching files or events.

Preserve evidence before restoring trust

Inventory FortiMail branch and installed build, restrict management reachability, and disable IBE where your mail workflow permits. Compare the listed file hashes, examine the archive configuration and ui=cron events, then retain evidence and investigate matches before returning that system to normal service. Files written before an upgrade can remain on the appliance; pair the version check with a trusted-image comparison and management-access history.

The immediate verification is concrete: the IBE setting reads disabled if you chose that workaround, an untrusted network cannot reach management if you chose access restriction, and any file or log hit has a recorded incident disposition. Treat the forthcoming releases as a remediation plan, with interim access controls carrying the load today.

1-minute read

CISA added CVE-2026-104286 to its exploited-vulnerabilities catalog on October 1, with an October 4 action date. Fortinet says unauthenticated HTTP or HTTPS requests can exploit path traversal and NULL-character handling in FortiMail’s GUI to write arbitrary files on the appliance. The company reports exploitation in the wild and supplies file and log indicators. Fortinet found the flaw internally; Gwendal Guégniaud is credited.

Inventory FortiMail appliances and their installed versions. Fortinet lists affected branches 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. Its 8.0.2, 7.6.7 and 7.4.9 release targets are upcoming; 7.2 operators should plan a move to a remediated build on 7.4 or later; 7.4.0–7.4.8 remain affected. The CVE JSON carries older conflicting targets, so follow the current PSIRT table and confirm branch-specific guidance for 7.0 systems.

Restrict management access to a trusted private network, or set config system encryption ibe to set status disable as Fortinet instructs. Where feasible, use both and verify the disabled setting and the blocked management route from an untrusted network. Forensic triage is separate: compare appliance files such as /data/etc/ld.so.preload and /data/lib/liblog.so with Fortinet’s published hashes, and inspect ui=cron events and archive configuration for remote-ip[79[.]141[.]169[.]187]. Preserve and investigate a match before returning that appliance to service; an installed-build check alone misses files written earlier.