On Thursday, October 1, Fortinet published PSIRT advisory FG-IR-26-175 for CVE-2026-104286, a critical FortiMail flaw the vendor confirmed was already being exploited in the wild. The numbers are the ugly kind: CVSS 9.8, unauthenticated, arbitrary file write on the appliance that reads your mail. The same day, CISA added it to the Known Exploited Vulnerabilities catalog with a federal remediation deadline of October 4.
Here is the part that should reorder your week: the fixed builds do not exist yet. Versions 8.0.2, 7.6.7, and 7.4.9 are listed as upcoming. For the 7.2 branch, there will be no fix at all. Those users have to migrate to 7.4 or later.
Every shop has a patch plan. Very few have a no-patch plan. This is the no-patch drill, and the order of operations matters more than the speed. Contain first, hunt second, upgrade last. And the upgrade is not the finish line. A file-write primitive on a Linux appliance means the attacker may already own the box at a level no patch can reach. Fortinet's own indicators include a dynamic-linker preload implant and backdoored service binaries. A patch closes the door. It does not escort out whoever already walked through it.
What the flaw actually is
Two weaknesses chained together: a path traversal flaw (CWE-22) and an improper neutralization of NULL bytes (CWE-158) in the FortiMail web interface. The traversal sequences move the write outside the directory the web server intends to confine it to, and an embedded NULL byte cuts off whatever suffix or filename the application appends. The net result is that an unauthenticated remote attacker chooses both the location and the name of a file written to the underlying system, over plain HTTP or HTTPS. No credentials, no session, no user interaction. The CVSS 3.1 vector reads AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.
The vulnerable surface is the web-facing GUI, and Fortinet's workaround points at Identity-Based Encryption (IBE) as the entry route. If that interface is reachable from the internet, the appliance is exposed.
| Branch | Affected versions | Fixed in |
|---|---|---|
| 8.0 | 8.0.0 through 8.0.1 | 8.0.2 (not yet released) |
| 7.6 | 7.6.0 through 7.6.6 | 7.6.7 (not yet released) |
| 7.4 | 7.4.0 through 7.4.8 | 7.4.9 (not yet released) |
| 7.2 | 7.2.0 through 7.2.9 | No fix. Migrate to 7.4 or later. |
The flaw was found internally by Gwendal Guegniaud of Fortinet's Product Security team. Fortinet has not attributed the attacks to anyone, and has not said when the first exploitation started or how many systems are affected. Treat those as open questions, not as reassurance.
What attackers do with a file write on a mail appliance
Arbitrary file write sounds like an integrity problem. On an appliance it is a foothold problem. Fortinet's published indicators show the expected playbook: plant persistence, backdoor the services, then use the box. The indicators to hunt:
| Indicator | Detail |
|---|---|
| Added files | /data/lib/liblog.so, /data/bin/webconsole, /data/bin/mailservice, /data/etc/ld.so.preload (SHA-256 hashes published in the advisory) |
| Modified files | /bin/smit, /data/etc/httpd.conf, /data/migadmin.tar.gz |
| IPs | 79.141.169.187, 45.129.0.192 |
| Archive account | An account named archive234 created from the CLI, configured to ship archives to 79.141.169.187 under /uploads. That reads like exfiltration staging. |
| Cron | A root cron entry executing something under /migadmin |
| Log patterns | An admin logout with a null UI value, IBE decryption errors reporting invalid Base64 data, failed internal-user logins |
The one worth dwelling on is /data/etc/ld.so.preload. That file tells the dynamic linker to load a shared object into every process on the box. It is persistence by design, and it survives a version bump. If that file is not stock, your appliance is not yours anymore.
Censys counts roughly 2,800 FortiMail hosts on the public internet, honeypots excluded, with about 350 of them serving on an HTTPS port. Small surface, high value. Every one of those is a mail path, which is exactly why this one is in the KEV catalog with a four-day federal deadline.
The response checklist
- Inventory first. List every FortiMail appliance, its exact build, and whether its web interface is reachable from the internet. You cannot triage what you have not counted. Fortinet's table is build-specific: 7.4.8 is vulnerable and 7.4.9 will not be, so "we are on 7.4" is not an answer.
- Apply the workaround now, not when the patch lands. Either disable IBE support:
config system encryption ibe
set status disable
end
or remove the management interface from the internet and restrict it to a trusted private network. The workaround stops new exploitation attempts. It does not clean anything already planted.
3. Hunt before you patch. Check the added and modified files against the SHA-256 hashes in the advisory, search your firewall and proxy logs for the two IPs, look for the archive234 account, the /migadmin cron entry, and the log patterns. Preserve logs and support bundles before you touch anything. Evidence first, remediation second.
4. If the appliance was internet-exposed on a vulnerable build, assume compromise until forensic triage says otherwise. CISA's required action references BOD 26-04 and explicitly calls for forensic triage, not just mitigation. That wording is deliberate. An internet-facing mail appliance with a known exploited unauthenticated file write is not a "probably fine" box.
5. If you find indicators, rebuild instead of just upgrading. A linker implant and backdoored binaries are not removed by installing 7.4.9 over the top. Restore from a known-good image or factory reset, rotate credentials, and then upgrade to the fixed build when it ships.
6. Plan the 7.2 migration now. There is no 7.2 fix coming, so "waiting for the patch" is not a plan for that branch. A branch migration to 7.4 (and then 7.4.9 when it releases) needs its own change window, compatibility check, and rollback plan. Start the paperwork today.
7. When the fixed builds land, validate before deploying. Confirm the exact version against the advisory and verify the image hash from Fortinet's download portal. Then deploy it like any critical appliance update: staged, with a snapshot or backup taken first.
The boring lesson, as usual, is the durable one. The shops that handle this well are not the ones with the fastest patch fingers. They are the ones whose runbook has a step zero for "there is no patch." Contain, hunt, rebuild if needed, then upgrade. That order is the whole post.
Sources
- Fortinet PSIRT advisory FG-IR-26-175, "CVE-2026-104286", October 1, 2026 — affected versions, workarounds, and indicators of compromise.
- Fortinet warns of critical FortiMail flaw exploited in zero-day attacks — BleepingComputer, October 1, 2026.
- Critical FortiMail zero-day exploited in the wild (CVE-2026-104286) — Help Net Security, October 2, 2026.
- Oct 2 Advisory: Fortinet FortiMail Path Traversal Vulnerability — Censys, October 2, 2026.
- FortiMail Zero-Day Under Active Exploitation — SOCRadar, October 2, 2026.
- Critical Fortinet FortiMail 0-Day Vulnerability Actively Exploited in Attacks — CybersecurityNews, October 2, 2026.
