Cut-paper illustration of a FortiMail mail-gateway appliance receiving a fresh padlock on its front panel while dark paper roots representing a persistent attacker implant grow out of its back

Fortinet Shipped the FortiMail Patches. If You Stopped There, You Missed the Point.

FortiMail 8.0.2, 7.6.7, and 7.4.9 landed on October 5, 2026. That is the good news. The disclosure of CVE-2026-104286 was October 1, which means attackers had four days of unpatched, actively exploited runway before any fix existed. FortiMail Cloud was remediated the same day, and Fortinet updated advisory FG-IR-26-175 twice, on October 5 and October 7, adding the indicator-of-compromise list.

The bad news is the part that does not fit on a change ticket. Patching closes the hole. It does not evict whoever already walked through it. If your runbook says "patched, resolved," reopen it. This post is the forensic triage playbook for every FortiMail operator who had an exposed box during the zero-day window.

What the attackers did with the window

CVE-2026-104286 is a path traversal (CWE-22) combined with null byte mishandling (CWE-158) in FortiMail's IBE portal, giving an unauthenticated attacker arbitrary file write. CVSS 9.8. Fortinet's own Product Security team found it while chasing live attacks, not during a code audit. That detail matters: from day one, this was evidence from real intrusions, not a theoretical primitive.

And the evidence shows the attackers did not stop at a file write. They used it to build persistence:

  • A dynamic-linker implant. Attackers added /data/etc/ld.so.preload and /data/lib/liblog.so. Anything listed in ld.so.preload loads into every process that starts afterward. That is system-wide code execution, not a file sitting on disk.
  • Backdoor services. Two new binaries appeared on compromised boxes: /data/bin/webconsole and /data/bin/mailservice.
  • Tampered system files. /bin/smit and /data/etc/httpd.conf were modified, and /data/migadmin.tar.gz was replaced. Overwriting the web server's own configuration is a reliable way to regain access later.
  • An exfiltration account. An archive account named archive234 was configured to ship mail data to attacker infrastructure via the appliance's /uploads directory.
  • Two command-and-control addresses. 79.141.169.187 and 45.129.0.192, tied to the campaigns Fortinet observed.

A preload implant hides from the very processes it loads into. That is exactly why CISA's KEV entry for this CVE carries a forensic-triage flag: check for prior compromise, do not assume patching alone makes you safe. The federal remediation deadline of October 4 has already passed, so if you are only getting to this now, you are in incident-response territory, not patch-management territory.

The playbook: hunt, then patch, then verify

The order matters. A reboot or an upgrade destroys forensic state. Do this in sequence:

  1. Inventory. List every FortiMail box running 8.0.0-8.0.1, 7.6.0-7.6.6, 7.4.0-7.4.8, or 7.2.0-7.2.9. Note which ones had IBE enabled and reachable from outside your network. One estimate puts 1,000 to 10,000 FortiMail systems exposed internet-wide; your scope starts with your own fleet.
  2. Preserve evidence first. On any exposed box, export logs, snapshot the configuration, and image the disk if you can, before you patch or reboot. If an indicator matches later, you will want this.
  3. Hunt the IOCs. Use the checklist below. A single match means confirmed compromise. Stop treating it as a patch task and start treating it as an incident: isolate the appliance, preserve everything, and plan a rebuild from known-good media. A mail gateway sees everything, so rotate every credential it ever touched and assume mail content was read.
  4. Patch the clean ones. Upgrade to 8.0.2, 7.6.7, or 7.4.9 depending on your branch. Patching a confirmed-compromised box without rebuilding first is just patching over someone else's backdoor.
  5. If you cannot patch today, buy time properly. Disable IBE if you do not use it (config system encryption ibe, then set status disable), and pull the management interface off the internet into trusted networks only. These workarounds reduce exposure. They are not cleanup.
  6. Keep the receipt. Add file-integrity monitoring after patching. A permanent watch on /data/etc/ld.so.preload is nearly free, and it turns this whole incident into a durable control. If that file ever changes again, you will know before the advisory drops.

The IOC checklist

Check every exposed appliance against this list, drawn from Fortinet's advisory and the follow-up analyses:

Indicator Where to look What it means
/data/etc/ld.so.preload exists at all ls -la /data/etc/ld.so.preload Implant. This file should not exist on a clean box.
/data/lib/liblog.so present ls -la /data/lib/liblog.so Malicious shared object
/data/bin/webconsole or /data/bin/mailservice present ls -la /data/bin/ Attacker-added backdoor services
/bin/smit, /data/etc/httpd.conf, /data/migadmin.tar.gz modified Hash against known-good baseline Tampered system files
Root cron entries referencing /migadmin Review crontabs Persistence mechanism
Archive account archive234, or archive configs pointing to 79.141.169.187 Archive account configuration Exfiltration setup
Outbound connections to 79.141.169.187 or 45.129.0.192 Firewall, proxy, NetFlow logs, any retention C2 contact
POST /ibe requests containing ../ and a NUL byte Web access logs Exploit attempts, including probes that may not have succeeded

One honest caveat: Fortinet has not named an actor, and CISA lists ransomware use as unknown. Do not let any report turn "unconfirmed" into "ransomware crew" in your incident notes. Hunt what the IOCs tell you, not what the rumor mill suggests.

The 7.2 problem

There is no fixed 7.2.x build. None. Fortinet's guidance is migration to 7.4 or later. If you are still on 7.2, this is not a patch conversation, it is a migration conversation: build a fresh appliance on 7.4.9+, migrate configuration, cut mail flow over, and run the triage checklist on the old box before you retire it. Do not decommission evidence before you have checked it.

The part that outlives this CVE

Patching is a hygiene task. Triage is a judgment task. The instinct to close the ticket at "upgraded" is exactly what the attackers counted on when they built persistence designed to survive the fix. Two habits are worth keeping permanently: management interfaces that never face the internet again (the workaround that should have been the default all along), and a file watch on the one path whose modification means the whole box is suspect. Boring controls beat exciting incident responses, every time.

Sources