FortiMail CVE-2026-104286: unauthenticated file write exploited as a zero-day

Fortinet has confirmed that CVE-2026-104286, a critical flaw in its FortiMail secure email gateway, is being exploited as a zero-day. The bug lets an unauthenticated attacker write arbitrary files to the underlying system through a crafted HTTP or HTTPS request to the management interface — and in the attacks observed so far, that file write is being used to drop a persistent backdoor onto the appliance. CISA added it to the Known Exploited Vulnerabilities catalog on October 1 and gave federal agencies until October 4 to act, with forensic triage required. If your FortiMail management interface was reachable before the patch, patching is step one, not the finish line.

Developing story — first published 09:20 CEST (07:20 UTC), October 2, 2026. Updated as the vendor and CISA publish more.

At a glance

CVE	CVE-2026-104286
Product / affected versions	FortiMail 8.0.0–8.0.1 · 7.6.0–7.6.6 · 7.4.0–7.4.8 · 7.2.0–7.2.9 (NVD additionally lists 7.0.0–7.0.9)
Fixed in	8.0.2+ · 7.6.7+ · 7.4.9+; 7.2.x has no fixed 7.2 build — migrate to 7.4.9+
CVSS	9.8 Critical · CVSS 3.1, scored by Fortinet · AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Exploited in the wild	Yes — Fortinet confirms active exploitation; zero-day
CISA KEV	Added 2026-10-01; federal due date 2026-10-04 (BOD 26-04, forensic triage required)
Official advisory	FG-IR-26-175

What Fortinet disclosed

The advisory, FG-IR-26-175, describes two weaknesses working together: an improper limitation of a pathname to a restricted directory (CWE-22, classic path traversal) and an improper neutralization of a NULL byte or NULL character (CWE-158). Chained, they let a request escape the directory the web server intends to confine it to and plant a file anywhere the service can write. No credentials, no session, no user interaction — the CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, a clean 9.8.

Arbitrary file write on an appliance is not a theoretical "integrity" impact. On a Linux-based device it is the primitive you build a foothold out of: write a shared object, write a web component, write a loader, and you own the box. That is exactly what the in-the-wild activity does. Per the vendor and corroborated by BleepingComputer and The Hacker News, attackers are using the write to install a dynamic-linker implant and backdoor services, then beacon out.

"We patched the morning the advisory dropped." That sentence describes a box now running clean code — and, if it was internet-reachable beforehand, possibly still running someone else's liblog.so. The patch closes the door. It does not escort out whoever already walked through it.

Who is exposed, and how to check

Every supported FortiMail branch below the fixed build is affected. Check the running version from the CLI:

get system status

Read the Version line. You are exposed if it is in any of these ranges: 8.0.0–8.0.1, 7.6.0–7.6.6, 7.4.0–7.4.8, 7.2.0–7.2.9. The NVD record additionally lists 7.0.0–7.0.9; the Fortinet advisory table does not enumerate a 7.0 branch, so if you are on 7.0.x, treat yourself as affected and move to a fixed 7.4 build regardless. Exposure that matters most: a management interface (HTTP/HTTPS admin, and the Identity-Based Encryption / IBE portal) reachable from the internet.

Remediation

1. Am I affected? Run get system status and compare the Version line to the ranges above. Then establish whether the admin interface or the IBE portal has been internet-facing at any point — your edge firewall rules and any reverse proxy logs answer this, not the appliance alone.

2. Patch — exact fixed versions. Upgrade to the first fixed build on your branch, verbatim from FG-IR-26-175:

Branch	Fixed version
FortiMail 8.0	8.0.2 or above
FortiMail 7.6	7.6.7 or above
FortiMail 7.4	7.4.9 or above
FortiMail 7.2	No fixed 7.2 build — upgrade to 7.4.9 or above

3. Can't patch now? Compensating controls. Fortinet gives two, and both are worth applying even after you patch. Disable Identity-Based Encryption, which is in the exploited path:

config system encryption ibe
    set status disable
end

And restrict the management interface to trusted networks — ideally remove it from the public internet entirely and reach it over VPN or a jump host. An unauthenticated network-reachable bug stops mattering the moment the network is not reachable.

4. Hunt for compromise (do this even after patching). This is the step most write-ups skip, and on a confirmed-implant zero-day it is the one that counts. The vendor published concrete indicators — treat their presence as compromise, not a maybe. Added or modified files on the appliance:

• /data/etc/ld.so.preload (added) — the persistence linchpin: anything listed here is loaded into every process. Maps to ATT&CK T1574.006, Hijack Execution Flow: Dynamic Linker Hijacking, and is covered by the public Sigma rule Modification of ld.so.preload.
• /data/lib/liblog.so (added) — the preloaded object; functions as a rootkit (T1014) hiding the rest.
• /data/bin/webconsole and /data/bin/mailservice (added) — backdoor services on a web/mail appliance (T1505.003, Web Shell / server component).
• /bin/smit, /data/etc/httpd.conf, /data/migadmin.tar.gz (modified).

Network side, the observed C2 addresses are 79.141.169[.]187 and 45.129.0[.]192 — hunt your egress and firewall logs for any FortiMail talking to them (ATT&CK T1071.001). A mail gateway that historically only emits SMTP suddenly opening outbound web sessions to an unfamiliar host is the signal, with or without those exact IPs. Initial access itself maps to T1190, Exploit Public-Facing Application, in your web/proxy logs as anomalous requests to the admin interface.

5. Eradicate and verify. A patched-but-implanted appliance is still an owned appliance. If any indicator is present, the defensible path is a clean reinstall of a fixed image rather than deleting files you found — a dynamic-linker rootkit exists precisely to make "I removed the files" unreliable. Rotate every credential the box held or could see: admin accounts, LDAP/AD bind credentials, SMTP relay secrets, API tokens, certificates. Confirm clean after the rebuild, not before.

What is not known yet

As of this writing, Fortinet has not published the identity of the actor, the full exploitation timeline, or how many appliances were hit. CISA lists known ransomware-campaign use as Unknown. There is no public proof-of-concept named by the sources, which does not mean one does not exist — an unauthenticated file-write with active exploitation should be assumed weaponized. We will update this post as primary sources add detail.

Catching the implant your appliance can't admit to

The uncomfortable part of this CVE is that the box you would ask "are you compromised?" is the same box running the attacker's liblog.so, built to lie. The durable answer lives on the network, not on the host. Zero Hunt's AI Traffic Analysis is a deep-learning model with four parallel inference heads — suspicious traffic, malware classification, attack-type identification, application fingerprinting — trained on billions of PCAP sequences and running locally on the appliance GPU at 2.7+ Gbit/s. A FortiMail that has only ever spoken SMTP suddenly beaconing outbound web sessions to a never-seen ASN is exactly the deviation it flags while it is happening, independent of whether the host's own logging has been subverted.

That pairs with the question patching leaves open: is the file-write path actually closed on your configuration? Zero Hunt's autonomous AI red team answers it the way an attacker would — a 10-agent swarm running black-box against the appliance, with the Exploit Forge iterating a runnable proof until it demonstrates the path or confirms the fix holds, every finding Ed25519-signed at write time. It runs on-premise on private models, with a human in the loop for anything that touches the target, so the evidence never leaves your perimeter. For how this fits a continuous cadence, see our guide to automated penetration testing; for the broader Fortinet-appliance pattern, our FortiSandbox agentless CVE analysis.

One compliance note worth making early: under BOD 26-04 this KEV entry carries a forensic-triage requirement, and for EU operators the NIS2 Article 23 reporting clock runs from when you became aware. Supervisors will test that awareness date against your own alerts and logs — which is an argument for having the network-side evidence, signed and time-stamped, before anyone asks. If your FortiMail was exposed, start the review now.