FortiMail Zero-Day CVE-2026-104286: Disable IBE, Restrict Access and Hunt for Compromise

Plenty of Windows shops run FortiMail in front of Exchange Online, on-premises Exchange or another mail platform. For them, this is the job for this week.

What the flaw does​

Fortinet describes CVE-2026-104286 as two weaknesses combined: a path traversal bug (CWE-22) and improper handling of NULL bytes (CWE-158). In Fortinet's words, quoted by BleepingComputer, the combination can write arbitrary files on the underlying system over crafted HTTP or HTTPS requests. The attacker doesn't need to log in first.

CISA's Known Exploited Vulnerabilities (KEV) catalog uses the same description. It lists the related weaknesses as CWE-22| CWE-158.

The severity score is about as high as it gets. Rapid7's vulnerability database lists a CVSS 3.1 Base Score: 9.8 with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. In plain terms:

• Network-reachable: the attacker only needs to reach the web interface over the network.
• Low complexity: no unusual conditions are needed.
• No privileges and no user interaction: nobody has to click anything and no account is needed.
• High impact on confidentiality, integrity and availability: an attacker who succeeds can effectively take over the appliance.

BleepingComputer says the bug affects the FortiMail management interface. HOL, a vulnerability-tracking site that wrote up the advisory, adds that the vulnerable path is the GUI component that backs Identity Based Encryption (IBE). That fits with Fortinet's main workaround, which is to turn off IBE. Treat HOL's description as secondary analysis, not Fortinet's own wording.

Fortinet says Gwendal Guégniaud of its Product Security team found the bug internally. Attackers apparently found it too. Fortinet hasn't said when exploitation began, how many systems were hit, or who is behind the attacks.

Section summary: An unauthenticated attacker can write files over HTTP or HTTPS, which can lead to code execution on the appliance that handles your company's email.

Affected versions: check the CVE record too​

Fortinet's advisory, as reported by BleepingComputer, lists these vulnerable versions:

The CVE description text matches those ranges. Strix's CVE page quotes it as covering FortiMail 8.0.0 through 8.0.1, FortiMail 7.6.0 through 7.6.6, FortiMail 7.4.0 through 7.4.8, FortiMail 7.2.0 through 7.2.9.

The structured "affected software" data in the same record says something different. Strix, citing the CNA record on CVE.org, lists 8.0.0; >= 7.6.0, <= 7.6.5; >= 7.4.0, <= 7.4.6; >= 7.2.0, <= 7.2.9; >= 7.0.0, <= 7.0.9. The OffSeq threat feed shows the same ranges, also including the 7.0 branch. SecurityOnline's summary lists 8.0.0, 7.6.0, 7.4.0, 7.2.0, 7.0.0 as affected.

Two practical points follow:

1. Don't use a scanner's version range to rule yourself out. Some tools read the structured data, and those ranges are narrower at the top end (7.6.5 versus 7.6.6, 7.4.6 versus 7.4.8). A scanner could report a 7.4.8 box as clean even though Fortinet's advisory text lists it as vulnerable.
2. If you still run FortiMail 7.0, assume you're exposed. The structured data includes the 7.0 branch, and the published text doesn't mention it either way. Both can't be fully right. Until Fortinet clarifies, assume the worse case.

Section summary: Use the widest version range you can find. If your FortiMail runs 7.0 through 8.0.1, treat it as vulnerable until Fortinet says it isn't.

The workarounds​

Fixed builds aren't out for 7.4, 7.6 or 8.0, so mitigation comes first. Fortinet offers two options.

Option 1: Disable IBE​

From the FortiMail CLI:

config system encryption ibe
set status disable
end

This switches off Identity Based Encryption, which FortiMail uses to send encrypted mail to outside recipients through a pickup portal. If your legal, HR or finance teams use that feature for sensitive messages, those workflows will stop. Before you run the command:

• Check whether IBE is actually used in your environment. Many deployments never turned it on.
• If it is used, tell the affected teams and set up another secure-delivery method, such as Microsoft Purview Message Encryption if you're on Microsoft 365.
• Write down the change so you remember to turn IBE back on once you've patched.

Option 2: Keep the management interface off the internet​

Fortinet's alternative is to block internet access to the FortiMail management interface, or limit it to trusted private networks. A management GUI facing the internet was already a risk; now it's an actively exploited one.

Be careful with what this option covers. It restricts the management interface. It does not tell you to block all FortiMail traffic, and Fortinet hasn't published the exact vulnerable endpoint. If the IBE pickup portal has to stay public for outside recipients, Option 1 is the one that actually removes the exposure.

Section summary: Turn off IBE if you can live without it. Either way, restrict the management interface to trusted networks.

Signs you may already be compromised​

This flaw was exploited before anyone knew about it, so patching or mitigating doesn't prove you weren't hit. Fortinet published indicators of compromise (IOCs), and administrators should check for them.

Files added or modified​

The ld.so.preload entry is the one to worry about most. On Linux, that file makes the system load a library into every program that starts. Adding it, along with a planted liblog.so, is a common way for attackers to hide inside a system and survive reboots. (That's general Linux tradecraft, not something Fortinet stated about this campaign.)

Network indicators​

Fortinet listed 79[.]141.169.187 and 45[.]129.0.192 as IP addresses associated with the attacks. Search your firewall, proxy and NetFlow logs for any traffic to or from those addresses.

Log entries to look for​

Fortinet's advisory includes sample log events. The most telling one shows an archive account called archive234 created from the CLI. Its remote destination is 79.141.169.187, with the remote directory /uploads. In other words, someone may have set up FortiMail's own email-archiving feature to copy mail to an attacker's server. That's a tidy way to steal mail without installing anything extra. The log entry shows the account was configured, though, not that any data was actually sent.

Other sample entries include a cron job executing a command related to /migadmin, an administrator logout event, an IBE decryption error due to invalid Base64 encoding, and failed login attempts. The IBE decryption error ("Invalid Base64 Encoding at pos 0. Character=0x2a") is worth searching for on its own, since it ties exploitation attempts to the IBE code.

How to triage​

1. Preserve evidence before you change anything. Export logs and configuration, and take a snapshot if the appliance is a VM.
2. Review archive accounts. Remove any remote archive destination you don't recognize, after documenting it.
3. Compare file hashes against the table above, using Fortinet's own advisory as the reference.
4. Rotate credentials: FortiMail admin passwords, any LDAP or Active Directory bind accounts it uses, and SMTP relay credentials.
5. Assume email was exposed if you find any match, and bring in incident response. Mail that passed through a hijacked gateway may have been read or copied.

Finding no IOCs doesn't prove the appliance was never accessed. Attackers change their tools, and published indicators only describe what Fortinet has seen so far.

Section summary: Check archive accounts, file hashes, the two IPs and IBE decryption errors. Any match means incident response, not just a patch.

CISA's deadline​

CISA moved quickly. The KEV catalog entry for CVE-2026-104286 shows Forensic triage required per BOD 26-04: Yes - Date Added: 2026-10-01 - Due Date: 2026-10-04. The same entry says whether it's been used in ransomware campaigns is "Unknown."

The forensic triage requirement is the notable part. CISA isn't only telling federal agencies to mitigate; it's telling them to check whether they were already breached. A three-day deadline, under a directive that requires forensic work, shows how seriously CISA takes this one. Private companies aren't bound by it, but it's a reasonable benchmark for your own response.

Fortinet told BleepingComputer it is communicating with relevant government organizations, including CISA, on the content of this advisory.

The bigger picture​

Fortinet edge devices have been a favorite target for years. Earlier exploited bugs in FortiOS SSL-VPN, FortiManager and FortiWeb all led to rushed patching. SecurityOnline notes that Fortinet appliances also rank among the most targeted edge devices. Their bugs often land in the KEV catalog within days of disclosure.

To be fair to Fortinet, its own team found this bug, disclosed it with IOCs, and gave customers workarounds before fixes were ready. That's better than staying quiet until a patch ships. But "found internally" and "exploited as a zero-day" in the same advisory means attackers found it before or around the same time. The 7.4, 7.6 and 8.0 branches have no fixed release yet, so customers are depending on configuration changes for now.

The broader point applies to any appliance in front of your mail. An email gateway sees every message coming in and going out. That makes it valuable to defend and just as valuable to steal from, as the rogue archive account shows. If you use Microsoft 365, take a fresh look at whether that box is properly isolated and monitored.

Checklist for FortiMail administrators​

1. Inventory every FortiMail appliance and VM, including that 7.0 box in the DR site.
2. Disable IBE with the CLI commands above, if your business can do without it.
3. Restrict management interface access to trusted internal networks right away.
4. Hunt for the IOCs: file hashes, the two IP addresses, the archive234 archive account, and IBE Base64 decryption errors.
5. Escalate any match to incident response and assume mail was exposed.
6. Plan the upgrade: 7.2 users move to 7.4 or later. Everyone else watches for 7.4.9, 7.6.7 and 8.0.2 and installs them as soon as Fortinet releases them.
7. Re-enable IBE only after patching, and after you've confirmed the appliance is clean.

Patches are still pending, so for now your protection comes down to two CLI commands and a firewall rule. Apply them before an attacker finds your appliance.