Skip to content
Advertisement
Security October 10, 2026 • 9 min read

CVE-2026-104286 FortiMail: Check, Patch, Verify 7.2-8.0

Generic rack-mounted email security appliance lit by a thin cyan edge, for the CVE-2026-104286 FortiMail checklist

The CVE-2026-104286 FortiMail flaw is under active exploitation, and Fortinet scores it 9.8 on CVSS. Advisory FG-IR-26-175 says an unauthenticated attacker can write arbitrary files through crafted HTTP or HTTPS requests. The workaround stops new requests from landing. It does not show whether an attacker already used the route.

Advertisement

This guide follows one order of work. Check the firmware, search the logs for Fortinet’s published strings, disable IBE, then plan the upgrade by branch. Every command and string below comes from Fortinet’s advisory or its CLI reference.

Key takeaways
  • Fortinet rates CVE-2026-104286 at CVSS 9.8 and reports exploitation in the wild.
  • Disabling IBE is a stopgap, not a fix.
  • Search system event logs for O=/migadmin and encryption logs for Invalid Base64 Encoding.
  • FortiMail 7.2 has no fix, so Fortinet says to move to 7.4 or above.
  • FortiMail Cloud customers need no action, according to Fortinet's 7 October clarification.

Triage: CVE-2026-104286 Impact on FortiMail

This is a FortiMail path traversal that needs no login. Fortinet files it under CWE-22 and CWE-158, a path traversal combined with improper handling of NULL characters. The vector link in the advisory shows network access, low complexity, no privileges and no user interaction.

The advisory lists the impact as execution of unauthorized code or commands. It also marks the flaw as known exploited and lists no virtual patch. Fortinet names the GUI as the component, so web-facing interfaces are where to look first.

CISA added the flaw to its Known Exploited Vulnerabilities catalog on 1 October, the day of the advisory, according to SOCRadar. The Cloud Security Alliance notes that outlets differ on the federal due date. The catalog entry itself is the authoritative source for that deadline.

Advertisement

Other edge appliances follow the same pattern. The NetScaler build and config check makes the point for another exposed device: an upgrade closes the hole but says nothing about earlier access.

Rank Units by Exposure

Position raises the stakes. Wiz notes that FortiMail is an email security gateway, so compromise could expose sensitive communications and allow lateral movement into internal networks.

Four groups cover most estates. First come affected units that publish webmail or IBE pages to the internet, and those get the mitigation and the log search on the same day. Second come affected units reachable only from private networks, which can wait for a scheduled upgrade. Third are 7.2 units, which need a migration plan. Fourth is FortiMail Cloud, which needs no action.

That order follows from the advisory, whose alternative mitigations both turn on who can reach the interface. It also answers the inline-gateway question: reach decides urgency, not position in the mail path.

Five-step flow: check firmware, search logs, disable IBE, upgrade, verify

Step 1: Check the Running Firmware

Run get system status on each unit. Fortinet’s CLI reference says the output includes the firmware version, build number and date. Newer releases also report HA mode and role, which helps when you manage a pair.

Advertisement

Then compare the version line with the table in the upgrade section. For example, the reference shows a line reading FortiMail-VM v7.6.2, build753. A unit on 7.6.2 would sit inside the affected 7.6.0 through 7.6.6 range.

Boundary builds matter. A unit on 7.4.8 is the last affected build in its branch, and 7.4.9 is the first fixed one. The same reading applies to 7.6.6 against 7.6.7 and to 8.0.1 against 8.0.2. Every 7.2 build up to 7.2.9 is affected, and no 7.2 build is listed as fixed.

Log Hunting: Checking for Compromise

Fortinet published indicators tied to the attacks, so this step is a string match rather than a judgment call. Help Net Security reports that the files, IP addresses and log entries come from the observed attacks. The advisory names no console menu or CLI command for searching logs, so use whichever export or SIEM you already run.

Start with the network indicators. The advisory lists two IP addresses, 79.141.169.187 and 45.129.0.192, and writes them in defanged form. Search firewall and mail logs for both, in addition to the FortiMail logs.

Count the indicators: two IP addresses, three system event patterns and two encryption log patterns, seven in all. Load them into one saved query instead of running seven manual searches. Set the window to reach back past 1 October, because the advisory already reported exploitation on the day it was published.

Advertisement

Step 2: Search the System Event Logs

Fortinet lists three system-level patterns. The first is a debug-level cron line, run as root, whose shell command contains O=/migadmin. Treat any hit on that string as a reason to escalate.

The second is an admin logout message reading User admin logged out from (null). The third is a CLI configuration entry reading Added 'archive234' to 'archive account'. In the advisory’s example, that account has a remote destination at 79.141.169.187 and the remote directory /uploads.

Read the logout and configuration lines next to the cron entry. An admin logout appears in normal operation as well, so it proves little alone. An archive account that sends files to an address on the indicator list is a different matter.

Step 3: Search the Encryption Logs

Two encryption log patterns are listed. The first is an IBE decrypter exception that ends with Invalid Base64 Encoding at pos 0. Character=0x2a. The second is a failed internal login reading Internal user *@domain.tld failed to log in.

Searching on Invalid Base64 Encoding alone catches the exception without depending on the position or character values. Both searches carry one limit.

Advertisement
No hits: A clean search shows only that these strings are absent. It does not prove the unit was never reached.

A match moves the unit from patching to incident response. The advisory lists the strings but gives no clean-up procedure. Export the matching lines before you change anything, so the evidence stays intact.

The IBE Command Mitigation: Disabling IBE

Fortinet’s zero-day workaround is to switch off IBE, the identity-based encryption feature, as Help Net Security describes it. The advisory gives two routes. One is the GUI path Encryption, then IBE, then IBE Service set to off. The other is the CLI.

If a unit faces the internet and the log search will take hours, disable IBE first. The change is three commands, and it does not depend on the search result.

Step 4: Disable IBE From the CLI

Enter config system encryption ibe, then set status disable, then end. Fortinet gives these three lines in the advisory. They are the only CLI lines the advisory publishes for this mitigation.

Disabling IBE stops any workflow that depends on it. The advisory does not describe the service impact, so check whether recipients rely on IBE before you make the change.

The advisory lists two alternatives for units where IBE must stay on. One is to remove internet access to the FortiMail webmail interface or limit it to trusted private networks. The other, where a web application firewall sits in front, is a rule that blocks POST requests to /ibe when they contain ../, as the advisory words it.

The Hacker News describes the first alternative as restricting the management interface, so the cautious reading restricts both. Neither alternative fixes the flaw. The advisory also does not say whether the firewall rule covers encoded variants.

The three stopgaps work at different layers. Disabling IBE removes the feature, restricting webmail removes the network path, and the firewall rule filters one request pattern. Only the first two act without depending on a pattern match.

Firmware Upgrade Paths and Timeline

Fixed builds exist on three branches, and the fourth has no fix of its own. The table lists Fortinet’s affected range and the target for each branch.

Affected and fixed FortiMail versions
FortiMail 8.0 8.0.0 through 8.0.1, upgrade to 8.0.2 or above
FortiMail 7.6 7.6.0 through 7.6.6, upgrade to 7.6.7 or above
FortiMail 7.4 7.4.0 through 7.4.8, upgrade to 7.4.9 or above
FortiMail 7.2 7.2.0 through 7.2.9, upgrade to branch 7.4 or above

Branch 7.2 is the exception. Fortinet says to upgrade to branch 7.4 or above, so a 7.2 owner faces a migration rather than a patch window. Plan that move early, because the other three branches need only a point release.

Upgrade order follows the triage groups. Internet-facing units on 8.0, 7.6 and 7.4 go first, because each needs only a point release. Private-only units follow. Any 7.2 unit runs on the IBE mitigation while its migration is prepared.

How the Timeline Shifted After 1 October

The timeline shifted during the first week. Fortinet published the advisory on 1 October. The Hacker News described 8.0.2, 7.6.7 and 7.4.9 as upcoming at that point. The Cloud Security Alliance still listed all three as unreleased on 3 to 4 October.

Fortinet updated the solution on 5 October and clarified the cloud position on 7 October. The advisory says it moved FortiMail Cloud to v7.6.7 GA or v8.0.2 GA, so cloud customers need no action. That implies both builds exist. The advisory makes no such statement for 7.4.9, so confirm that build on the Fortinet support portal.

A multi-unit estate benefits from a per-branch matrix. The CVE-2026-21589 fixed-version matrix shows that format for eight Atlassian Data Center products.

Last verified: 10 October 2026, against FortiGuard advisory FG-IR-26-175, which Fortinet last updated on 7 October 2026.

Post-Fix Verification and Rollback

Verification has two parts: the firmware and the IBE state. Run get system status again and confirm the version is at or above the fixed build for the branch. That means 8.0.2, 7.6.7 or 7.4.9, and a unit moved from 7.2 should report 7.4 or above.

Then confirm the IBE state in the GUI. The advisory publishes no CLI read-back command, so the setting it names is Encryption, then IBE, then IBE Service. Fortinet gives no separate re-enable guidance either.

The sensible order is upgrade, verify the version, then re-enable IBE and watch the encryption logs for Invalid Base64 Encoding. The advisory frames the disablement as a workaround, which supports re-enabling only on a fixed build.

Rollback has limits. The advisory publishes no firmware downgrade procedure, so read the release notes for the target build before you upgrade. Undoing the workaround means switching IBE Service back on in the GUI, and nothing in the advisory supports doing that on a vulnerable build.

A short acceptance test closes the work. A unit passes when four conditions hold. The version is at or above the fixed build, the IBE state matches the plan, the seven indicators return no hits, and neither IP address appears in firewall logs.

Keep the log strings as a saved search after the upgrade. A fixed build closes the route, but it cannot show access that happened before the upgrade.

Frequently Asked Questions

01 Is FortiMail Cloud affected by CVE-2026-104286?
Fortinet says cloud customers need no action. The advisory states that FortiMail Cloud firmware was updated to v7.6.7 GA or v8.0.2 GA on 5 October. Only self-managed appliances on the affected branches need the checks in this guide.
02 Does disabling IBE fix CVE-2026-104286?
No. Fortinet lists disabling IBE as a workaround, and the fix is an upgrade on your branch. The workaround also does not show whether an attacker already reached the unit, so the log searches still apply.
03 Which fixed build covers FortiMail 7.2?
None. Fortinet lists 7.2.0 through 7.2.9 as affected, and its advisory says to upgrade to branch 7.4 or above. That makes 7.2 a migration, while the 8.0, 7.6 and 7.4 branches need only a point release.
04 Can a web application firewall block the attack?
The advisory offers it as an alternative, not a fix. Where a firewall sits in front, it can block POST requests to /ibe that contain a dot-dot-slash sequence. Fortinet does not say whether the rule covers encoded variants, so treat it as a stopgap.

Where This Checklist Stops

This checklist covers detection and mitigation, not clean-up. Fortinet’s advisory publishes no remediation steps for a compromised unit, so a log match needs an incident response decision. It also names no log search command, no IBE read-back command and no service impact for disabling IBE.

FortiMail Cloud customers can skip it, because Fortinet says it patched that service. This guide is an analysis of 7 sources, mainly the FortiGuard advisory and Fortinet’s CLI reference. It involved no hands-on testing, and the CISA catalog entry itself was not loaded.

Advertisement
B
Written By
Bidi Waid
Advertisement

Leave a Reply

Your email address will not be published. Required fields are marked *

Please don’t include links, website addresses or promotional text — comments that do will not be posted.