On October 1, 2026, Fortinet published a security advisory for a vulnerability in FortiMail, its email security gateway, and acknowledged that the flaw is being exploited in the wild. The US Cybersecurity and Infrastructure Security Agency added the vulnerability to its Known Exploited Vulnerabilities catalog the same day and gave federal civilian agencies until October 4, 2026 to apply the fix or a workaround. The patches that fully resolve the issue have not been released yet, which means a significant share of the email security perimeter of many organizations is currently defended by a CLI command rather than a software update.
What the Vulnerability Does
The flaw is tracked as CVE-2026-104286 and carries a CVSSv3 score of 9.8, which places it at the top of the severity scale. It combines a path traversal weakness, categorized as CWE-22, with improper neutralization of NULL byte characters, CWE-158. The practical effect is that an unauthenticated attacker can write arbitrary files on the underlying system of a FortiMail appliance by sending crafted HTTP or HTTPS requests. No credentials are required to do this.
The affected versions are FortiMail 8.0.0 through 8.0.1, 7.6.0 through 7.6.6, 7.4.0 through 7.4.8, and 7.2.0 through 7.2.9. Fortinet will fix the issue in versions 8.0.2, 7.6.7, and 7.4.9, none of which have been released at the time of the advisory, and the company advises 7.2 users to upgrade to the 7.4 branch or above once fixes ship. The vulnerability was discovered internally by Gwendal Guégniaud of the Fortinet Product Security team.
What Compromise Looks Like
Fortinet shared indicators of compromise so administrators can check whether their appliances have been touched. The listed attacker infrastructure includes the IP addresses 79.141.169[.]187 and 45.129.0[.]192. The file indicators are more revealing. Files that were added include /data/lib/liblog.so, /data/bin/webconsole, /data/bin/mailservice, and /data/etc/ld.so.preload. Modified files include /bin/smit, /data/etc/httpd.conf, and /data/migadmin.tar.gz.
The presence of a modified or added ld.so.preload file deserves particular attention, because that file controls which shared libraries the dynamic loader loads into processes at startup. Tampering with it is a well known technique for running attacker controlled code inside legitimate processes, which is a hallmark of backdoor installation rather than a simple opportunistic scan. Fortinet did not disclose when or where the attacks were observed, how many appliances were compromised, or who is behind them, so the full scope is still unknown.
What To Do Right Now
Until the fixed versions are available, Fortinet offers two workarounds. The first is to disable support for IBE, the identity-based encryption feature, with the following CLI commands:
config system encryption ibe
set status disable
end
The second is to disable internet access to the FortiMail management interface entirely, or restrict it to a trusted private network. Administrators should also compare the file indicators and IP addresses above against their own logs and appliances, since the patch is not out and detection is currently the only way to know whether a specific deployment was targeted.
Why This Matters Beyond the Appliance
An exploited FortiMail is not just an infrastructure problem to hand to the network team. The appliance sits directly in the path of your email. It sees your inbound mail before your users do, it applies anti-spam and anti-phishing filtering, and in many deployments it handles outbound mail too. An attacker with arbitrary file write access on that box has a vantage point over the entire mail stream, which means they can potentially read mail, weaken the filtering that protects your users, and manipulate messages in transit.
That is precisely why domain-level authentication standards like DMARC matter so much in an incident like this. DMARC is not enforced on your gateway. It is enforced by the receiving mail server, which independently verifies SPF and DKIM alignment against the domain in the visible From header before deciding what to do with a message. A receiver applying your p=reject policy will refuse spoofed mail claiming to be from your domain no matter what any compromised intermediary appliance did or did not do along the way.
There is a second, less comfortable implication. If an attacker gains enough control over mail infrastructure, they may be able to send mail that passes authentication legitimately, because it genuinely originates from infrastructure you control. That is not a DMARC failure. DMARC answers the question of whether a message really came from the domain it claims to come from, and mail from a compromised legitimate sender does. What DMARC gives you here is different: your aggregate reports become an early warning system. A sudden change in authentication results, unexpected sending sources, or volume anomalies in your DMARC data is exactly the kind of signal that surfaces a compromised internal component quickly, if someone is watching the reports.
What This Means for Your Program
Treat the gateway as a target, not just a shield. Security appliances that sit in the mail path are high value targets precisely because of where they sit. They need the same patch discipline, the same exposure restrictions on management interfaces, and the same compromise monitoring as any internet facing system.
Layer the controls. A single appliance, however good, is one component. DMARC enforcement at receivers, DKIM signing done at a layer the attacker did not reach, and monitoring of aggregate reports together give you protection that does not depend on any single box staying clean.
Watch your DMARC reports during any security incident. During and after an event like this, authentication telemetry is one of the fastest ways to confirm whether mail flow was tampered with or whether new sending sources appeared. Reports that nobody reads cannot warn anybody.
Reduce management plane exposure everywhere. The workaround Fortinet recommends, keeping management interfaces off the internet, is advice that applies to every mail infrastructure component you run, not only FortiMail.
The Takeaway
A 9.8 rated zero-day with no patch available, actively exploited, on an appliance that guards the email of thousands of organizations is a serious situation by any measure. The organizations that weather it best will be the ones that applied the workaround immediately, checked the indicators of compromise, and had a second layer of domain-level authentication already in force, so that a single compromised component could not translate into unrestricted freedom to impersonate their domain.
Email threats do not schedule themselves around your patch cycle. Excello Mail gives you continuous visibility into your DMARC, SPF and DKIM posture, so you can see anomalies in your authentication data the moment they appear. Sign up for free to Excello Mail and know exactly what your domain is telling the world today.