FortiMail Zero-Day CVE-2026-104286: No Patch Yet, Here Is What to Do

If you run Fortinet FortiMail and the IBE service is switched on, switch it off today or take the webmail interface off the internet. Fortinet says the flaw tracked as CVE-2026-104286 is being exploited, and as of October 4, 2026 its advisory still describes the fixed builds as “upcoming”. Then check whether someone has already used it, because the attacks Fortinet describes change the appliance’s mail archiving settings.

This article covers what Fortinet has confirmed, where the public records disagree with each other, and the order to work in.

What Fortinet disclosed

On October 1, 2026, Fortinet published advisory FG-IR-26-175. It describes the flaw as a path traversal weakness (CWE-22) combined with improper neutralization of a NULL byte (CWE-158) that “may allow an unauthenticated attacker to write arbitrary files on the underlying system via crafted HTTP or HTTPS requests.”

The advisory adds: “This has been reported to be exploited in the wild, customers are urged to apply the workaround below.”

CVSS (Common Vulnerability Scoring System) is the industry-standard 0 to 10 severity scale; this score uses version 3.1.

The workaround and the indicators both point at one feature: IBE, or identity-based encryption. Fortinet’s administration guide describes it as a scheme that “uses identities (such as email addresses) to calculate encryption keys.” In practice it is the feature that lets FortiMail send an encrypted message to an outside recipient, who then opens it through a web link. That web-facing piece is what the workaround turns off.

Fortinet’s advisory does not say whether IBE is enabled by default, and we could not confirm it from the documentation we read. Check your own configuration rather than assuming either way.

Affected and fixed builds, according to Fortinet’s advisory

We read the advisory on October 4, 2026. Its timeline showed a single entry, “2026-10-01: Initial publication”, and the solution column still used the word “upcoming”. We found no Fortinet statement giving a release date. That status can change at any time, so read the advisory itself before you plan around it.

Note what this means for the 7.2 branch: Fortinet lists no fixed 7.2 build. The stated path is a migration to 7.4 or later, which is a larger change than a patch release.

The CVE record does not match the advisory

This is the part most likely to cause a wrong decision this week.

The CVE record is published by Fortinet as the CVE Numbering Authority (the organization authorized to describe CVE IDs for its own products). We retrieved it on October 4, 2026; it was last updated on October 2, 2026. It disagrees with the advisory, and with itself:

The CVE record’s solutions field also mentions FortiRecorder, a different product that the advisory does not mention at all.

Why this matters: vulnerability scanners and asset inventories usually match on the structured version data, not on the advisory text. A tool reading that data could report FortiMail 8.0.1, 7.6.6, 7.4.7 or 7.4.8 as not affected, while Fortinet’s advisory lists all four as affected. The record’s solutions field would also lead you to treat 7.6.6 as the fix when the advisory says 7.6.7.

We do not know which source Fortinet will correct. Until it does, the cautious reading is the advisory’s wider range, plus the 7.0 branch that only the CVE record lists. If your scanner says a FortiMail build on these branches is clean, verify the build number by hand.

What attackers have been doing

Fortinet’s advisory lists indicators of compromise rather than a narrative, but the indicators tell a story. Three kinds of entry appear in the system event log examples it publishes:

• A scheduled job running as root: a log line beginning msg="(root) CMD (/bin/sh -c 'O=/migadmin ..., with ui=cron.
• An administrator logout with no interface recorded: msg="User admin logged out from (null)."
• A new mail archive account pointing off the appliance: msg="Added 'archive234' to 'archive account'" with destination[remote], remote-ip[79.141.169.187] and remote-directory[/uploads].

The third one is the consequence to worry about. An archive account with a remote destination sends copies of mail to another server. Beazley Security, summarizing the same indicators, describes “attackers creating a remote mail archive account” that “sends archived mail” to that address. For a mail gateway that sees an organization’s inbound and outbound email, that is a continuing leak of message content, not a one-time break-in.

The advisory also lists two entries from the encryption logs: an IBE decryption error ending 'Invalid Base64 Encoding at pos 0. Character=0x2a', and a failed login for an internal user written as *@domain.tld.

Fortinet names two IP addresses: 79.141.169.187 and 45.129.0.192. Attacker addresses change, so treat a match as strong evidence and a non-match as weak evidence.

Two security firms, Truesec and Beazley Security, additionally list files they say were added or modified on compromised appliances. Their lists overlap but are not identical. Beazley Security presents the files as Fortinet’s indicators and publishes hashes for each; we did not see a file list in the advisory text we were able to read, so we attribute them to those firms:

No source we read attributes the activity to a named group, gives a count of affected organizations, or says when exploitation began. CISA’s catalog entry lists ransomware use as “Unknown”.

What to do, in order

1. Find out whether you are exposed

Treat the appliance as exposed if it runs a build on the 8.0, 7.6, 7.4, 7.2 or 7.0 branch at or below the versions in the tables above and its web interface accepts requests from networks you do not control. Record the exact build number and whether the IBE service is on. Fortinet’s advisory does not spell out the exact conditions for exploitation, so do not rule an appliance out on the IBE setting alone until you have confirmed it in the configuration.

2. Preserve logs before you change the configuration

The indicators Fortinet published are log entries. Export the system event logs and encryption logs off the appliance first, and take a snapshot if FortiMail runs as a virtual machine. A compromised appliance can have its local logs altered, and a later upgrade or rebuild may discard them. Our piece on logging for incidents rather than dashboards covers why off-device copies matter.

3. Apply the workaround

Fortinet’s primary workaround is to disable IBE feature support. In the GUI, the advisory gives the path as Encryption, then IBE, then set IBE Service to off. From the CLI:

config system encryption ibe
set status disable
end

The trade-off is functional: with the service off, FortiMail stops providing IBE encrypted delivery. If your organization relies on it for outside recipients, tell the people who use it before you switch it off, and decide what they should use in the meantime.

The advisory lists two alternatives:

• Disable access to the FortiMail webmail interface from the internet, or limit access to a trusted private network.
• If a web application firewall sits in front of FortiMail, block POST requests to /ibe that contain ../.

Our assessment, not Fortinet’s: treat the firewall rule as the weakest of the three. A rule that matches the literal string ../ depends on how the firewall decodes and normalizes a request before matching, and this flaw involves a second trick (the NULL byte) alongside the traversal. Removing the exposed feature or the exposed interface does not depend on matching the attacker’s exact input.

4. Check for compromise

Search the exported logs for the patterns above:

• Any archive account you did not create, especially one with a remote destination. archive234 is the name in Fortinet’s example; an attacker can choose a different one, so review every archive account, not only that name. Beazley Security gives the GUI location as Email Archiving, then Archive Account.
• Cron entries running shell commands as root.
• Administrator logouts recorded as coming from (null).
• IBE decryption errors mentioning Invalid Base64 Encoding.
• Connections to or from 79.141.169.187 and 45.129.0.192 in firewall and proxy logs, not only on the appliance.

If you have shell-level visibility through Fortinet support, compare against the file list above. A clean result lowers the likelihood of this specific activity. It does not prove the appliance is clean.

5. If you find indicators

Fortinet’s advisory gives no recovery procedure, so this is general incident response practice rather than vendor guidance:

• Isolate the appliance and open a case with Fortinet support.
• Remove the unauthorized archive account, and work out from its creation time in the logs how long mail was being copied. That period defines what may need to be reported under your breach notification obligations.
• Rotate credentials the appliance holds or has seen: administrator passwords, LDAP bind accounts, API keys and TLS private keys.
• Plan a rebuild from known good firmware rather than cleaning files by hand. Several of the reported files, including an ld.so.preload entry, are the kind used to reload attacker code after a restart.

6. Upgrade when the builds ship

Watch the advisory for the release of 8.0.2, 7.6.7 and 7.4.9, and upgrade when your branch is available. Keep the workaround in place until then. If you run 7.2, start planning the move to 7.4 now, since that is the only path the advisory gives.

What the CISA deadline means for you

CISA added CVE-2026-104286 to its Known Exploited Vulnerabilities (KEV) catalog on October 1, 2026, the same day Fortinet published. The catalog entry sets a due date of October 4, 2026 and marks forensic triage as required.

Two points of scope. First, the due date comes from Binding Operational Directive 26-04, which, according to Tenable’s analysis of the directive, applies to US Federal Civilian Executive Branch agencies and is not binding on private companies. Second, the required action in the entry is to “apply mitigations in accordance with vendor instructions” or to “discontinue use of the product if mitigations are unavailable.” With the fixed builds listed as upcoming, the vendor instruction available today is the workaround.

For everyone outside the US federal government, read the three-day window as a statement of urgency, and note that CISA paired the mitigation with a compromise check. That is the same sequence as the steps above.

The pattern worth fixing afterward

This section is editorial analysis rather than reported fact.

A mail gateway is an unusually valuable thing to compromise. It reads every message, it is trusted by the mail servers behind it, and it is expected to accept connections from anywhere. Three habits reduce the cost of the next advisory like this one:

• Turn off web-facing features you do not use. The exposed surface here was one optional feature. An inventory of which optional services are enabled on each edge device turns “are we affected?” into a lookup.
• Alert on configuration changes that redirect data. A new archive destination, a new forwarding rule or a new administrator account on a mail system should raise an alert whoever makes the change.
• Do not let one data source decide exposure. This week the advisory and the CVE record disagree. A process that checks the vendor advisory for any actively exploited flaw would catch that.

We covered the same patch-then-hunt sequence for a different edge device in the Citrix NetScaler zero-days, and the general response order in what a zero-day is and how to respond to one. For where this belongs in your queue, see the vulnerability backlog that never shrinks.

Sources and verification

Checked on October 4, 2026. We did not test the workaround or the indicators on a FortiMail appliance; the commands and log patterns are quoted from Fortinet’s advisory.

Vulnerability ManagementIncident Response