Byte by Mahmud logoByteby Mahmud
The FortiMail Zero-Day With No Patch: Anatomy of a 72-Hour Scramble
Technology5 min read7 views

The FortiMail Zero-Day With No Patch: Anatomy of a 72-Hour Scramble

Mahmud Hasan

Mahmud Hasan

October 2, 2026

Fortinet published advisory FG-IR-26-175 on October 1, 2026, and the numbers did all the talking: CVE-2026-104286, CVSS 9.8, no authentication required, active exploitation confirmed. FortiMail — the mail gateway that sits in front of thousands of corporate inboxes — had a hole in its management interface that lets an unauthenticated attacker write files onto the appliance through a crafted HTTP or HTTPS request. Here's the part that turned a bad advisory into a genuinely ugly week: the fixed releases were announced, not available. Three of the four affected branches had no patch, and CISA gave federal agencies until October 4 to remediate. That left everyone else with a workaround, a 72-hour clock, and a choice between staying vulnerable or breaking their own encrypted email.

What actually broke

The advisory describes a two-part bug in the FortiMail management interface: path traversal (CWE-22) combined with improper handling of a null byte (CWE-158). A crafted request smuggles a null byte past the path check, the truncated path escapes its intended directory, and the request writes a file wherever the attacker wants it. No login, no user interaction — just a web interface the attacker can reach.

"File write" sounds abstract until you look at what Fortinet's investigators actually found on compromised appliances: a new /data/etc/ld.so.preload pointing at a new /data/lib/liblog.so. That's the oldest trick in the Linux rootkit book — ld.so.preload forces every process on the box to load the attacker's shared library. The step from arbitrary file write to full compromise is one library drop away, and the IOCs say the attackers took exactly that step.

The patch gap is the real story

Disclosure day is supposed to be the day fixes ship. This time it wasn't. FortiMail 8.0.0–8.0.1, 7.6.0–7.6.6, 7.4.0–7.4.8, and 7.2.0–7.2.9 are all affected. The fixed releases — 8.0.2, 7.6.7, 7.4.9 — were listed as "upcoming," which in appliance-vendor language means they arrive whenever QA signs off. Only 7.2 admins get an immediate path: jump to the 7.4 branch or later. Everyone else was told to apply the workaround and wait.

CISA, meanwhile, added the CVE to its Known Exploited Vulnerabilities catalog on October 1 with a remediation deadline of October 4. A 72-hour federal deadline for a bug with no fixes on three major branches — the compliance clock and the vendor release train are running on different calendars, and defenders are stuck in between.

The timeline so far: advisory and KEV listing on October 1; fixes for 7.4, 7.6, and 8.0 still pending at disclosure; federal deadline October 4. Watch Fortinet's advisory for the fixed-release announcements — "upcoming" is not a date.

Why losing a mail gateway is worse than losing a server

A mail gateway sees every message that enters or leaves an organization. The IOCs show the attackers understood that perfectly: one compromised appliance had a rogue archiving account — archive234 — configured to forward mail archives to 79.141.169.187/uploads. They didn't just break in; they reconfigured the box's own compliance-archiving feature into an exfiltration pipeline.

And about "just don't expose the management interface": fair instinct, wrong target. FortiMail's IBE (Identity-Based Encryption) components are commonly reachable by external recipients, because that's how people outside the company retrieve encrypted messages — the secure-mail portal has to face the internet. When the customer-facing portal shares attack surface with the vulnerable code path, the boundary you drew on the whiteboard doesn't hold. Fortinet's own workaround points at where the vulnerable code lives: it disables IBE support entirely:

config system encryption ibe
set status disable
end

The honest triage: keep encrypted mail working and stay exposed to an unauthenticated file-write bug, or kill IBE and degrade mail flow yourself while waiting for binaries that don't exist yet. Neither is a fix; both are bets.

Are you already owned?

Closing the management interface off from the internet today doesn't answer yesterday's question. Fortinet published a concrete IOC set — check it against your appliances before assuming anything:

  • Files that shouldn't exist: /data/lib/liblog.so, /data/bin/webconsole, /data/bin/mailservice, /data/etc/ld.so.preload
  • Files that shouldn't have changed: /bin/smit, /data/etc/httpd.conf, /data/migadmin.tar.gz (Fortinet published MD5/SHA256 hashes for all of these — verify against them)
  • Network: outbound connections or archive accounts pointing at 79.141.169.187 or 45.129.0.192
  • Logs: root cron entries referencing /migadmin, an admin logout with a null interface value, IBE decryption errors reporting invalid Base64 data, failed internal-user logins

One match is a reason to investigate; two is a reason to start incident response. If the appliance is compromised, a patch won't un-ring the bell — preserve logs, rebuild, rotate credentials. Check backup and virtual appliances too; they get forgotten and attackers know it.

What to do right now

  • Inventory first. Which FortiMail versions are you running? All of 8.0.0–8.0.1, 7.6.0–7.6.6, 7.4.0–7.4.8, and 7.2.0–7.2.9 are in scope.
  • Apply the workaround — disable IBE or isolate the management interface to trusted networks — and queue the real patch: 7.4.9, 7.6.7, 8.0.2 when they land; 7.2 moves to the 7.4 branch now.
  • Hunt the IOCs before declaring yourself clean (checklist above).
  • Watch the advisory for fixed-release availability, then patch as if the CISA deadline applies to you — because your mail flowing through a known-exploited gateway is worse than any compliance finding.

One last thing the silence tells you: Fortinet hasn't named an actor or a victim count. That doesn't make the exploitation theoretical — the advisory confirms it's happening — it means the blast radius is unknown. Found internally by Fortinet's own Gwendal Guégniaud, exploited in the wild before disclosure, patches pending for most branches: "zero-day" is the right word for this one. Treat exposed appliances as suspect until proven otherwise.

References

Comments

Leave a comment

Your email stays private — only your name is shown.

More in Technology