FortiMail CVE-2026-104286: Exploited IBE Path Traversal Writes Files

On 1 October 2026 Fortinet published FG-IR-26-175 for CVE-2026-104286, a path traversal in FortiMail that lets an unauthenticated attacker write arbitrary files on the underlying system through crafted HTTP or HTTPS requests. Fortinet said it had been reported as exploited in the wild. CISA added it to the Known Exploited Vulnerabilities catalog the same day with a federal due date of 4 October.

Fortinet rates it Critical, CVSS 3.1 base score 9.8. The issue was discovered internally by Fortinet's product security team. The workaround and the published indicators both point at FortiMail's Identity Based Encryption (IBE) feature.

What's affected

Per Fortinet's advisory, as updated on 5 and 7 October:

The 7.2 branch gets no fix. Fortinet's guidance is to move to 7.4 or later. The CVE record published on 1 October lists slightly different ranges, including a 7.0 line. Use the advisory, which Fortinet has updated since, and treat 7.0 appliances as needing an upgrade too.

FortiMail Cloud was remediated by Fortinet on 5 October by moving all firmware to 7.6.7 GA or 8.0.2 GA, so cloud customers don't need to act.

The bug combines CWE-22 path traversal with CWE-158 improper neutralization of null bytes. Fortinet's WAF workaround, blocking POST requests to /ibe that contain ../, shows where the entry point is.

How to check if you're exposed

Get the firmware version from the CLI:

get system status

Check whether IBE is enabled. Fortinet's advisory places the setting in the GUI under Encryption, IBE, IBE Service, and in the CLI under config system encryption ibe.

Then hunt using Fortinet's published indicators. The advisory lists two source IPs, shown defanged here:

79[.]141.169.187
45[.]129.0.192

Search firewall, WAF and reverse proxy logs for both. Then check FortiMail's own logs for the event patterns in the advisory:

• A system event log entry for a cron job running as root with a command that begins /bin/sh -c 'O=/migadmin.
• A config change adding an archive account named archive234 with a remote destination of 79[.]141.169.187 and remote directory /uploads. That is mail archiving pointed at the attacker, a quiet way to copy mail out.
• An admin logout event from (null).
• Encryption log errors from FortiMail::IBE::DecrypterMediaIn with Invalid Base64 Encoding at pos 0. Character 0x2a, alongside failed logins for internal users with a wildcard address like *@domain.tld.

Also review every mail archive account on the appliance and compare it against what you configured. Any account with a remote destination you don't recognize is a red flag.

What to do now

1. Upgrade to 8.0.2, 7.6.7 or 7.4.9 or later. Move 7.2 and older appliances to a supported branch.
2. Until you can upgrade, apply Fortinet's workaround and disable IBE:

config system encryption ibe
    set status disable
end

3. If you can't disable IBE, restrict the FortiMail webmail interface to trusted networks, or block POST requests to /ibe containing ../ at a WAF in front of the appliance.
4. Block the two IoC IPs at the perimeter and search back through logs for them.
5. If you find the archive account or the cron entry, treat the appliance as compromised. Remove the rogue archive account, preserve logs, rebuild from known good firmware and config, and rotate admin credentials and any LDAP or SMTP relay credentials stored on the device. Assume mail that passed through it during the exposure window was copied.

Why it matters

Mail gateways see every message in and out of an organization. An attacker who can write files on one doesn't need to stay noisy. Adding an archive account that ships mail to an outside server, as Fortinet's indicators show, is both persistent and hard to spot in routine reviews.

Features you don't use are attack surface you pay for anyway. IBE is an optional component. If your organization never turned on encrypted mail for external recipients, disabling it now costs nothing and closes this path.

Try it yourself

Make a list of every optional feature enabled on your mail gateway, VPN and firewall, and mark which ones have an owner who can say why it's on. Anything without an owner is a candidate to disable before the next advisory.

This demo shows how a security team tracks newly disclosed, actively exploited zero-days against the products it runs:

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Fortinet PSIRT FG-IR-26-175
• CVE-2026-104286 record
• CISA Known Exploited Vulnerabilities Catalog