CVE-2026-104286: FortiMail zero-day lets attackers write files without logging in

What it is

FortiMail’s Identity-Based Encryption (IBE) service is the web portal where external recipients read encrypted mail. On affected versions, crafted requests to it could use path traversal and a NULL-byte trick to write files anywhere on the appliance, with no login. Writing files on a Linux appliance usually means code execution, and Fortinet rates the impact as “execute unauthorized code or commands.”

Fortinet found the bug internally but disclosed it as already exploited. Fixed releases followed four days after the advisory.

What the attackers did with it, according to the log entries in Fortinet’s advisory: they ran commands through cron, used the admin account, and added a mail archive account called archive234. That account sends archived mail to a remote server, 79.141.169.187, which is one of the attacker IPs. In other words, a copy of your organization’s mail was being shipped out.

Am I affected?

You’re affected if you run FortiMail 7.2.0 to 8.0.1 on-premises or as a VM, and the IBE web service is reachable by attackers. IBE has to be reachable from the internet for external recipients to use it, so if you use IBE, assume it’s exposed.

FortiMail Cloud was fixed by Fortinet on 5 October 2026.

Check whether IBE is enabled under Encryption > IBE: IBE Service is on or off.

What to do

1. Upgrade to 8.0.2, 7.6.7 or 7.4.9. FortiMail 7.2 gets no fix, so move to 7.4 or later.

2. If you can’t upgrade right away, disable IBE. This breaks encrypted-mail pickup for external recipients until you upgrade, so warn whoever relies on it.

config system encryption ibe
    set status disable
end

Other options from Fortinet’s advisory:

• Restrict the webmail/IBE interface to trusted networks.
• If a WAF sits in front of FortiMail, block POST requests to /ibe that contain ../.

3. Check for compromise (below), whatever your patch status. The bug was exploited before disclosure, so a patched appliance may already carry attacker changes. If you find any:

• Remove unknown archive accounts and administrators.
• Rotate admin passwords and any credentials stored on the appliance.
• Contact Fortinet support about rebuilding the device, since file write gives attackers ways to persist.
• Treat archived or relayed mail as potentially read by the attacker, and loop in your incident response and legal teams.

Detection

From Fortinet’s advisory:

• Unknown mail archive accounts with a remote destination. Review the archive accounts in FortiMail’s archiving settings, and look for the event log entry “Added ‘archive234’ to ‘archive account’” with destination[remote], remote-ip[79.141.169.187] and remote-directory[/uploads].
• Cron running commands you didn’t schedule, such as a system event with ui=cron and msg="(root) CMD (/bin/sh -c 'O=/migadmin ...".
• Admin sessions from nowhere: “User admin logged out from (null).”
• IBE decryption errors in encryption logs: “Caught BufferException(2), BufferImpl.cpp:973, ‘Invalid Base64 Encoding at pos 0. Character=0x2a’” next to “Internal user *@domain.tld failed to log in.” These are typical of exploitation attempts.
• Connections to or from 79.141.169.187 and 45.129.0.192, including outbound FTP or SFTP from the appliance.