Critical Fortinet FortiMail Zero-Day (CVE-2026-104286) Actively Exploited: Unauthenticated File Write Flaw Exposes Email Security Gateways Worldwide

A CVSS 9.8 vulnerability lets remote attackers write arbitrary files without credentials. Fortinet’s emergency advisory FG-IR-26-175 offers workarounds, but fixes for several product branches are still pending.

Fortinet has disclosed a zero-day in its FortiMail email security platform that attackers are already exploiting, which puts thousands of enterprise appliances at immediate risk. The flaw, CVE-2026-104286, scores 9.8 out of 10 and lets an unauthenticated remote attacker write arbitrary files to an affected device with a specially crafted HTTP or HTTPS request. Fortinet published advisory FG-IR-26-175 on October 1, 2026 and told administrators to apply workarounds immediately. Permanent patches for several branches were still listed as upcoming at the time of disclosure.

The bug sits in the web-facing surface of the device that is supposed to inspect inbound and outbound mail, so exploitation turns the gateway against its owner. An attacker with arbitrary file write can potentially disable mail scanning, exfiltrate archived communications, install persistent backdoors, or pivot deeper into the network. Fortinet confirmed exploitation in the wild but has not attributed the attacks to a specific threat actor or said how many organizations are affected.

How CVE-2026-104286 works

The vulnerability combines two weaknesses: path traversal (CWE-22) and improper handling of NULL bytes (CWE-158). Understanding how they interact helps teams assess their exposure and write detection signatures.

Path traversal happens when an application fails to sanitize user-supplied input that references file system paths. A secure implementation keeps file operations inside a designated directory such as /var/www/html/. If input is not sanitized, an attacker can inject ../ sequences or absolute paths to escape that directory and read or write files elsewhere on the operating system. Fortinet’s advisory confirms that crafted web requests can make FortiMail write files outside the intended directory structure and into critical system paths.

NULL bytes make this worse. In C and C++, which underpin much of Fortinet’s firmware, a NULL byte (\0) normally terminates a string. If an application does not account for NULL bytes embedded in user input, an attacker can truncate strings at unexpected points, get past filename validation, or change how the operating system interprets a path. Paired with path traversal, that can let an attacker write a file that looks like it has one name or extension while the system treats it as something else, which smuggles malicious payloads past input validation.

What turns this from a high-severity bug into an actively exploited zero-day is that no authentication is required. The flaw is reachable through HTTP or HTTPS requests to the FortiMail web interface, with no administrator credentials, API token, or prior access. A single crafted request from any internet-reachable IP address can trigger the file write. Any FortiMail appliance with its management or web interface exposed to the internet is a potential target, and Shodan and Censys search data show thousands of them globally.

Fortinet’s advisory does not yet describe the full attack chain seen in the wild, and the vendor has not identified the threat actors responsible. The indicators of compromise published with FG-IR-26-175 do suggest that attackers are using the file write to persist, disable security controls, and set up covert data exfiltration, a pattern consistent with advanced persistent threat (APT) operations against email infrastructure.

Gwendal Guégniaud of Fortinet’s Product Security Incident Response Team (PSIRT) discovered the flaw internally. Several Fortinet disclosures over the past two years followed the same pattern, with internal discovery and then confirmed outside exploitation. That raises the question of whether attackers found the same flaw independently through reverse engineering, or whether a narrower disclosure came first. Fortinet has not commented, and it has not said when it first learned of exploitation compared with when it identified the bug internally. Teams should assume attackers may have known about the vulnerability before public disclosure and run retrospective log analysis accordingly.

Affected FortiMail versions

The flaw spans four version branches, from recent upgrades to legacy installations many organizations have not yet migrated. This table summarizes the affected and fixed versions in advisory FG-IR-26-175:

The 8.0 branch, the newest major release, has only two builds, so nearly every organization that upgraded to FortiMail 8.0 is affected. The 7.6 branch has seven affected sub-releases, which means the vulnerable code survived a long maintenance window. FortiMail 7.2 has no direct patch at all: Fortinet says administrators on that branch must migrate to 7.4 or later. Many enterprises run 7.2 in stable production and treat major upgrades as projects that need testing and change-management approval, so that is where the remediation gap is widest.

The fixed versions are minimum thresholds. An organization on FortiMail 7.4.3 is vulnerable even though it is on the 7.4 branch, because the fix does not arrive until 7.4.9. Check your exact build number against the affected range instead of assuming the branch is safe.

Indicators of compromise

Fortinet’s advisory lists indicators of compromise (IOCs) in three groups: file system artifacts, network indicators, and behavioral log anomalies. One indicator does not prove compromise, but several together should trigger a full incident response engagement.

File system artifacts

The advisory names files that attackers have created or modified on compromised appliances. Teams with shell access or log aggregation should check for these.

Newly added files:

• /data/lib/liblog.so: a shared library planted in a system library path. Legitimate FortiMail installations do not have a liblog.so here, so its presence suggests an attacker injected a malicious shared object to intercept or manipulate logging.
• /data/bin/webconsole: a binary in the data binaries directory. The legitimate web console component lives in standard firmware locations, so a file at this path is anomalous.
• /data/bin/mailservice: a rogue mail service binary at this path suggests an attacker replaced or supplemented the legitimate mail processing daemon.
• /data/etc/ld.so.preload: the most dangerous of the four. This file tells the Linux dynamic linker to load the listed shared libraries before any others, so an attacker who writes a malicious .so path into it gets code injection every time any binary runs. Fortinet explicitly flags it as a compromise indicator.

Modified files:

• /bin/smit: changes may indicate tampering with system management interfaces.
• /data/etc/httpd.conf: modifications to the Apache HTTP server configuration can enable attacker-controlled virtual hosts, reverse proxies, or hidden endpoints.
• /data/migadmin.tar.gz: altering the migration administration archive could let an attacker inject malicious configuration during an upgrade or migration.

Fortinet provides MD5 and SHA256 hashes for these files in the advisory. Compute the hashes of the corresponding files on your appliances and compare them with the published values. Treat any match as confirmed compromise.

Network indicators

Two IP addresses appear in the advisory’s IOC list. Block them at perimeter firewalls and search historical connection logs for them. They are defanged here to prevent accidental connections:

• 79[.]141.169[.]187
• 45[.]129[.]0[.]192

Search proxy logs, firewall session logs, and FortiMail’s own connection history for traffic to or from either address. The advisory also documents a suspicious configuration entry: an archive account named “archive234” set up to send email archives to 79.141.169.187 under an /uploads path. No standard FortiMail deployment includes this, and it is a purpose-built exfiltration channel. If your configuration contains an account or archive rule that references this IP address or the name “archive234”, treat the appliance as actively compromised.

Behavioral and log anomalies

Fortinet also lists log patterns that correlate with exploitation:

• Root cron entries that reference /migadmin. Legitimate FortiMail cron jobs do not typically point at migration administration paths, so such an entry suggests scheduled persistence.
• Admin logout events with a null interface value. An empty interface field is anomalous and may point to programmatic session manipulation rather than a person logging out.
• IBE decryption errors reporting invalid Base64 data. Repeated Base64 failures in FortiMail’s Identity-Based Encryption (IBE) module can indicate an attacker probing or tampering with the encryption subsystem, which matters because the recommended workaround disables IBE.
• Failed internal-user login attempts. Failed logins are common on their own, but a spike alongside other indicators may mean an attacker is attempting lateral movement within the appliance’s management framework.

Evaluate these signals together. A single IBE decryption error in normal operation proves nothing. A modified httpd.conf, a new ld.so.preload entry, outbound connections to the listed IP addresses, and an unfamiliar archive account all at once is a high-confidence compromise signal.

Immediate mitigation

Permanent firmware patches for multiple branches were still pending at disclosure, so Fortinet published interim workarounds. For internet-facing FortiMail deployments these are emergency measures for an actively exploited attack vector.

Disable IBE

The primary workaround targets Identity-Based Encryption, which appears to be where the path traversal and NULL byte flaws are triggered. In the FortiMail command-line interface (CLI), run:

config system encryption ibe
set status disable
end

This turns off IBE processing entirely, so any encrypted email workflow that depends on IBE will be disrupted. Given active exploitation, that trade-off is necessary. Fortinet has not provided a virtual patch or IPS signature as an alternative, which makes this CLI change the most direct protection available.

Restrict management interface access

Fortinet recommends removing internet access to the FortiMail management interface entirely. If the appliance has to stay reachable for administration, limit access to trusted private networks or specific administrator IP addresses through firewall policy. In practice that means:

• Disabling HTTPS management access on the WAN-facing interface.
• Allowing administrative access only on internal or dedicated management VLANs.
• Permitting management traffic only from known administrator workstations or jump hosts.
• Reviewing existing “trusted host” lists to make sure they have not grown beyond what is necessary.

This does not fix the vulnerability, because an attacker with network access to the management interface can still exploit CVE-2026-104286. It does shrink the attack surface from the whole internet to a few controlled sources.

Apply firmware updates when available

Watch Fortinet’s advisory page for fixed versions 8.0.2, 7.6.7, 7.4.9, and later. Because exploitation is confirmed, treat these patches as emergency changes and apply them outside normal change-management windows if your policy allows. For FortiMail 7.2 deployments, speed up the migration to 7.4 or later.

Why FortiMail is a high-value target

FortiMail sits inline in the mail flow, processes sensitive communications, holds encryption keys, and typically has network visibility into both internal and external segments. Compromising the email gateway is functionally the same as compromising the organization’s communication backbone. A single successful exploit can give an attacker years of archived email, enable business email compromise at scale, or provide a persistent foothold for lateral movement.

CVE-2026-104286 also has a predecessor to keep apart from it. CVE-2025-32756 was an earlier Fortinet zero-day that affected FortiMail alongside other products, including FortiVoice, with exploitation confirmed specifically against FortiVoice. The two flaws are independent: they differ in root cause, affected components, and exploitation context, and their IOCs, version ranges, and remediation steps are specific to each. Teams that responded to CVE-2025-32756 should not assume their FortiMail deployments are protected against this one. Fortinet’s product line spans firewalls, email gateways, voice systems, and SD-WAN appliances, and a codebase that large and varied can produce critical vulnerabilities in any of them.

The advisory also lists no virtual patch or IPS signature as an interim mitigation, which is unusual for a Fortinet disclosure of this severity. FortiGuard IPS typically provides virtual patches for critical vulnerabilities within hours. Fortinet has not said why one is missing here. Either the exploitation mechanism is hard to signature without disrupting legitimate FortiMail traffic, or the flaw sits in a component the IPS engine does not inspect. Neither explanation is confirmed. Either way, administrators carry more of the burden: the CLI workaround and network restrictions are the only protection until firmware ships.

Action plan for security teams

For CISOs, security operations managers, and administrators responsible for FortiMail, here is the advisory guidance as a sequence:

• Identify every FortiMail appliance in your environment and determine the exact firmware version on each. Compare against the affected ranges above. If an appliance runs an affected version and its management interface is reachable from the internet, treat it as potentially compromised until proven otherwise.
• Apply the IBE disable workaround through the CLI on all affected appliances. Restrict management interface access to trusted internal networks. Block the two IOC IP addresses (79.141.169.187 and 45.129.0.192) at all perimeter and internal firewalls. Preserve current system logs, configuration backups, and file integrity baselines before making further changes.
• Sweep every appliance for the IOCs. Check for the listed file artifacts, compute and compare hashes, review cron entries, look for the “archive234” configuration, and analyze logs for the behavioral indicators. If any are confirmed, start formal incident response, isolate the appliance from the network, and bring in forensic specialists. Do not reboot or re-image the appliance before preserving volatile evidence.
• Apply fixed firmware as it becomes available. For 7.2 deployments, start planning the migration to 7.4 or later now. Review all FortiMail configurations for unauthorized changes, unexpected administrative accounts, and unusual archive or forwarding rules. Extend log retention so historical evidence is not lost.
• Monitor advisory FG-IR-26-175 for updates, additional IOCs, and fixed-release availability, and subscribe to Fortinet PSIRT notifications. If all of your mail-flow security runs through one vendor appliance, consider a defense-in-depth design that does not.

Why this vulnerability is urgent

Four things make CVE-2026-104286 more dangerous than its CVSS score alone suggests.

It needs no authentication and no user interaction. There is no phishing email to trick an administrator, no credential to steal, no social engineering. An attacker sends a crafted HTTP or HTTPS request to a reachable FortiMail interface, which makes automated, large-scale exploitation trivial. FortiMail instances are easy to identify through default SSL certificates, HTTP response headers, and login page signatures, so a scanner can probe thousands of appliances in minutes.

The file write primitive is powerful. On a Linux-based appliance, arbitrary file write lets an attacker overwrite binaries, plant shared libraries, change configuration files, alter dynamic linker preload directives, and install persistent cron jobs. A remote code execution bug might need chaining with other flaws to persist, but file write alone is enough for a durable foothold. Fortinet’s IOCs, especially the ld.so.preload manipulation and the planted shared libraries, show attackers in the wild using exactly this.

The target is a security appliance. A compromised email gateway can silently disable anti-malware scanning, suppress phishing detection, switch off data loss prevention policies, and exfiltrate sensitive communications without raising alerts in downstream tools that trust the gateway’s verdicts. Many security operations centers are not instrumented to see this.

The patch gap leaves a window. Fixes are still listed as upcoming for multiple branches and there is no virtual patch, so the vulnerability is public, actively exploited, and not yet fixable through a standard firmware update. Disabling IBE and restricting network access reduce the risk without removing it, particularly for organizations whose mail flow makes losing IBE operationally painful.

What Fortinet has not said

CVE-2026-104286 combines a maximum-severity CVSS rating, unauthenticated remote exploitation, attacks in the wild, and a patch gap that leaves organizations relying on interim workarounds.

Fortinet’s advisory documents the IOCs thoroughly but leaves four questions open. It does not attribute the attacks to a named threat actor, say how many organizations are affected, publish a technical writeup of the full exploitation chain, or give a date for fixed firmware across all branches. Until that changes, the defensible posture is to assume exposure, apply the workarounds now, hunt for the IOCs, and prepare for the possibility that your appliances were compromised before the advisory went out.

Keep an eye on Fortinet’s security advisories, on CISA’s Known Exploited Vulnerabilities catalog for a possible addition of CVE-2026-104286, and on threat intelligence feeds for updated indicators or attribution. FortiMail is widely deployed across enterprise, government, and critical infrastructure environments.

This article will be updated as Fortinet releases fixed firmware, more IOCs, or further technical details about the exploitation campaign. Bookmark advisory FG-IR-26-175 for the latest guidance.

Disclosure timeline:

• October 1, 2026: Fortinet publishes advisory FG-IR-26-175, confirming CVE-2026-104286 and active exploitation.
• October 2, 2026: public disclosure and industry reporting begin. Fixed firmware versions are listed as upcoming for multiple branches.
• Pending: release of FortiMail 8.0.2, 7.6.7, 7.4.9, and migration guidance for the 7.2 branch.

If your organization has been affected by this vulnerability or has additional indicators of compromise to share, contact Fortinet’s PSIRT team through its official security response channels. Anonymous reports can also be submitted through industry CERT coordination centers.