FortiMail Zero-Day Under Active Exploitation

Fortinet has confirmed that CVE-2026-104286, a critical path traversal flaw in FortiMail, is being exploited in zero-day attacks, and CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on the same day the advisory went live.

Fixed builds are not yet available for most affected branches, so the primary response right now is to apply Fortinet’s workarounds and check exposed appliances for compromise. This post answers the operational questions security teams are asking: what the flaw is, which versions are affected, what has been confirmed, and what to do before patches ship.

What Happened With FortiMail?

Fortinet published advisory FG-IR-26-175 on October 1, 2026, disclosing CVE-2026-104286 and stating that the vulnerability has been reported as exploited in the wild. The same advisory urges customers to apply its workarounds until a security update can be installed.

Fortinet has not disclosed when exploitation began, how many appliances were compromised, or who is behind the activity, and told reporters it is coordinating with government agencies including CISA.

Unlike many edge device disclosures, this one was found internally rather than surfacing through pre-disclosure attacker activity reported by third parties.

What Is CVE-2026-104286?

CVE-2026-104286 is a path traversal vulnerability combined with improper NULL byte neutralization, classified as CWE-22 and CWE-158. It lets an unauthenticated attacker write arbitrary files to the underlying operating system by sending crafted HTTP or HTTPS requests to an affected FortiMail appliance.

Details of CVE-2026-104286 (SOCRadar Vulnerability Intelligence)

Fortinet assigns it a 9.8 CVSS v3.1 score, with the base vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, reflecting a flaw that is network-exploitable without authentication or user interaction and that fully compromises confidentiality, integrity, and availability. The flaw sits in the GUI component, and Fortinet records the impact as execution of unauthorized code or commands: an arbitrary file write against a mail security appliance can be chained into code execution and persistence, which is consistent with the indicators Fortinet published alongside the advisory.

Which FortiMail Versions Are Affected?

The flaw affects the FortiMail management interface across the 7.2, 7.4, 7.6, and 8.0 branches. As of October 2, 2026, no fixed build is available for any affected branch. The corrected 7.4, 7.6, and 8.0 releases (7.4.9, 7.6.7, and 8.0.2) are all listed as upcoming, and Fortinet’s guidance for the 7.2 branch is to migrate to a fixed 7.4 build once one is available. Until a fix ships, the workarounds are the primary response for every branch.

Does the Attack Require Authentication or Special Configuration?

No. Fortinet classifies the attack type as unauthenticated, and the CVSS vector confirms it: no privileges and no user interaction are required. An attacker does not need a valid FortiMail account to exploit the flaw, which is what makes internet-facing management interfaces the priority for remediation.

The exposed surface is the FortiMail GUI, which also backs the Identity Based Encryption (IBE) feature. An appliance running an affected build is at risk wherever that HTTP or HTTPS interface is reachable by an untrusted network. Appliances whose management interface is not exposed to the internet are at lower immediate risk, but Fortinet still directs all affected customers to apply a workaround or upgrade rather than treating limited exposure as equivalent to a fix.

Is CVE-2026-104286 a Zero-Day, and Who Is Behind the Attacks?

Yes, it qualifies as a zero-day. Fortinet confirmed exploitation in the wild in the same advisory that disclosed the flaw, meaning attacks occurred before a fix was broadly available. Fortinet marks the CVE as Known Exploited: Yes, and CISA added it to the KEV catalog on October 1, 2026, citing evidence of active exploitation.

No reliable public attribution has been established. Fortinet has not named a ransomware group, criminal operation, or state-sponsored actor, and CISA refers only to evidence of exploitation without identifying a specific group. The published indicators point to attacker behavior rather than a named actor: added and modified binaries on the appliance, a malicious ld.so.preload entry, tampering with the web server configuration, and an archive account configured to exfiltrate data to an external server.

Several facts remain unconfirmed and should be treated as investigation questions, not established campaign details: when the first attacks began, how many appliances were compromised, and whether mail content, credentials, or key material were accessed on any given system.

What Has CISA Said, and What Is the Deadline?

CISA added CVE-2026-104286 to the KEV catalog on October 1, 2026, based on evidence of active exploitation, and set a remediation due date of October 4, 2026. The entry falls under Binding Operational Directive 26-04, which also requires covered agencies to perform forensic triage to determine whether a system was compromised before the fix was applied.

The three-day window applies to Federal Civilian Executive Branch agencies, not to private-sector organizations. CISA nonetheless encourages all organizations to prioritize KEV vulnerabilities, and a remediation deadline that short is a clear signal of how urgent the agency considers an actively exploited, unauthenticated flaw on an internet-facing security appliance.

What Indicators of Compromise Did Fortinet Publish?

Fortinet published file, network, and log indicators in its advisory (FG-IR-26-175). The file indicators cover binaries and configuration files that were added or modified on compromised appliances, including a malicious shared library, a modified smit binary, a web console and mail service binary, a tampered httpd.conf, and an ld.so.preload entry used to load attacker code.

The table includes file indicators from Fortinet; SHA-256 hashes shown, MD5 also available in the advisory.

Fortinet listed two IP addresses tied to the activity, 79[.]141[.]169[.]187 and 45[.]129[.]0[.]192, with the former appearing in a log entry as the remote server for an attacker-created archive account named archive234 pointed at a /uploads directory. The advisory also shares example log events for a cron job running a /migadmin command, an administrator logout, an IBE decryption error caused by invalid Base64 input, and failed logins. Teams should hunt for these file changes, outbound connections to the listed hosts, and unexpected archive accounts or cron entries. Fortinet did not provide a virtual patch, and there is no published vendor or community network detection signature at this stage, so detection currently relies on these host-based artifacts and log review.

What Are the Workarounds, and Is a Workaround Enough?

Until fixed builds ship, Fortinet offers two workarounds. The first disables IBE support through the CLI:

config system encryption ibe

set status disable

end

The second option is to take the management interface off the internet or limit it to trusted private networks. Address internet-exposed management first and verify the restriction from outside, since a rule that still leaves HTTPS reachable does not reduce exposure, and note that disabling IBE removes any functionality that depends on it.

Neither workaround tells you whether an appliance was already compromised. Because exploitation began before disclosure, treat any affected appliance that was internet-reachable as a compromise-assessment candidate: preserve logs before disruptive changes, and if compromise is confirmed, rotate exposed secrets and rebuild from a trusted baseline.

Is There a Public Proof-of-Concept (PoC)?

As of October 2, 2026, there is no credibly verified, fully weaponized public exploit for CVE-2026-104286. Posts claiming to offer exploit code have circulated on exploit sharing sites, but their authenticity is unverified and they should not be treated as confirmed working PoCs. Major vulnerability trackers currently record no public PoC for this CVE.

The distinction does not lower the urgency. Fortinet and CISA have already confirmed real-world exploitation, which means attackers did not need a public PoC to weaponize the flaw. Remediation and compromise assessment should proceed on the basis of confirmed exploitation, not on whether exploit code has surfaced publicly.

How Can SOCRadar Help Track FortiMail Exposure?

With exploitation confirmed and fixes still pending for most branches, the immediate priority is knowing where affected FortiMail appliances are externally exposed. SOCRadar Attack Surface Management (ASM) module helps identify internet-facing FortiMail management interfaces across an organization’s perimeter, so teams can prioritize the exposed systems that matter most while patching and compromise assessment proceed. Cyber Threat Intelligence (CTI) module tracks CVE severity, KEV status, exploitation developments, and remediation updates, including the version-metadata discrepancies that can otherwise lead to the wrong remediation decision.

SOCRadar’s Vulnerability Intelligence, CTI module

What Should Organizations Do Right Now?

Confirmed exploitation and pending patches mean the response is containment and investigation, not a wait for fixed builds.

1. Inventory every FortiMail appliance: Find all deployments, including virtual and standby instances, and record the exact running build against the affected ranges in FG-IR-26-175 rather than a cached scanner feed.
2. Contain internet-facing management first: Remove public access to the FortiMail management interface or restrict it to trusted private networks, then verify the restriction externally.
3. Apply the IBE workaround where applicable: Disable IBE feature support on affected appliances, accounting for the loss of IBE-dependent functionality.
4. Assess exposed appliances for compromise: Treat any appliance that was reachable from an untrusted network as a candidate for triage; preserve logs and forensic state before disruptive changes, and check for the published file, IP, and log indicators.
5. Rotate secrets if compromise is suspected: Replace exposed credentials, API tokens, certificates, and DKIM key material, and rebuild or restore from a known-good state.
6. Upgrade when fixed builds ship: For 7.2, migrate to a fixed 7.4 build now; for 7.4, 7.6, and 8.0, install 7.4.9, 7.6.7, or 8.0.2 once Fortinet publishes them, and confirm the running build afterward.

Covered federal agencies face the October 4, 2026 KEV due date. Every other organization should set urgency by exposure and business impact, but confirmed exploitation means teams should not wait for public exploit code or attacker attribution before acting.