FortiMail CVE-2026-104286: Actively Exploited, No Patch Yet

Fortinet has disclosed a pre-authentication flaw in FortiMail with a CVSS score of 9.8, and CISA added it to its Known Exploited Vulnerabilities catalog the same day it was published. The remediation status is the part that matters: there is no patch. Every fixed build Fortinet lists(8.0.2, 7.6.7, 7.4.9) is marked as upcoming. What you have today is a workaround command and a set of indicators to hunt for.

CVE-2026-104286 is an unauthenticated arbitrary file write in the FortiMail GUI, classified as CWE-22 and CWE-158, with a remediation due date of October 4, 2026. Fortinet has published indicators of compromise, and the most instructive one is a file written to /data/etc/ld.so.preload — a dynamic-linker hook that survives patching and gives an attacker code execution on every process the appliance starts. Fortinet also states plainly that no virtual patch is available.

Key takeaways:

Actively exploited, unauthenticated, and reachable from the internet on a mail appliance. Treat this as an incident, not a maintenance ticket.
There is no fixed build. The mitigation is disabling IBE encryption or removing public access to the management interface.
Check /data/etc/ld.so.preload first. If it exists and you did not create it, you have a persistent, pre-patch implant.
FortiMail’s GUI is the affected component, not the SMTP path. A mail server with its admin interface exposed is the exposure.
Attribution is unknown, and Fortinet published no victim count. Do not assume either direction.

Table of Contents

What Fortinet actually published

Field	Value
CVE	CVE-2026-104286
Fortinet PSIRT ID	FG-IR-26-175
CVSS v3.1	9.8 — `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:P/RL:O/RC:C`
Weakness	CWE-22 (path traversal) and CWE-158 (improper neutralization of null bytes)
Affected component	GUI
Authentication required	None
Vendor impact statement	“Execute unauthorized code or commands.”
Known exploited	Yes — CISA KEV, added 1 Oct 2026, due 4 Oct 2026
Virtual patch	No

All values as stated in the Fortinet PSIRT advisory, published 1 October 2026.

Affected versions and the patch that does not exist yet

Fortinet lists four affected branches and a fix for each. Every one of those fixes is described as upcoming:

Affected	Fixed in	Status
8.0.0 – 8.0.1	8.0.2	Upcoming
7.6.0 – 7.6.6	7.6.7	Upcoming
7.4.0 – 7.4.8	7.4.9	Upcoming
7.2.0 – 7.2.9	Upgrade to the 7.4 branch	Upcoming

Fortinet PSIRT FG-IR-26-175. Do not report these builds as available until Fortinet ships them.

If you are on 7.2, your path is the 7.4 branch rather than a point release. Plan the upgrade window now rather than after the release ships and demand spikes.

The mitigation you have today

Fortinet offers one configuration workaround, or a topology change:

config system encryption ibeset status disable

Alternatively, remove public access to the management interface. That second option is usually the better one for a mail appliance, because the affected component is the GUI — an administrative interface reachable from the internet on a device that terminates mail is the whole exposure. Restricting it to a management network removes the attack surface rather than closing one path into it.

The indicator that tells you what happened

Fortinet published a full indicator set. The file list is the most useful part of the advisory, because it describes a persistence mechanism rather than a payload:

/data/lib/liblog.so — SHA256 8015f34dc84922b03688399d7f9fe7a00361789f7e420c7e2a2cdb23e75cef84
/bin/smit — modified, SHA256 77324ac428bde86d351fc5fc06f6d64a6bfe737dfb2743df1d4c5ac2418a5b6a
/data/etc/ld.so.preload
/data/bin/webconsole, /data/bin/mailservice, /data/etc/httpd.conf
/data/migadmin.tar.gz

ld.so.preload is the one to understand. It is a standard Linux mechanism: the dynamic linker reads it at startup and loads the named shared objects into every process, ahead of everything else. An attacker who writes a library into that file has not replaced a binary. They have inserted themselves below the application layer, into the loader that every subsequent process trusts. Upgrading or patching the application does not necessarily remove it.

So the triage order is: check the file, verify the hash if it exists, and treat its presence as confirmation of a root-level compromise that outlasts the patch.

The network indicators

79.141.169[.]187
45.129.0[.]192

Fortinet also describes log-level behaviour: an archive account named archive234 uploading to a /uploads path, and a Base64-encoded BufferException appearing in DecrypterMediaIn. The account naming is worth grepping for directly, it is the kind of artefact that survives long after the IP addresses rotate.

What is not known

Be precise about the limits of the current picture, because this is an actively exploited vulnerability and speculation is easy to generate:

Fortinet published no victim count and no confirmed mail-theft figures.
Attribution is unknown.
Compromise of the vulnerability is confirmed. Outcomes in any specific environment are not.
No virtual patch is available, which is unusual for a Fortinet product and worth weighing if you were counting on one.
The advisory was credited to Gwendal Guégniaud of Fortinet Product Security, i.e. found internally rather than reported.

If you run FortiMail, the sequence is: restrict management access now, apply the IBE workaround if you cannot, hunt for the indicators, and treat a positive ld.so.preload hit as a full root-level incident requiring reimage rather than remediation. When the fixed builds ship, patch anyway, the workaround and the patch are not substitutes.