Actively exploited FortiMail flaw prompts containment and compromise checks

Fortinet has disclosed a critical FortiMail vulnerability that it says has been exploited in the wild. With corrective builds still described as upcoming at the 3 October 2026 evidence cutoff, affected organisations were reliant on temporary controls and retrospective compromise checks.

Fortinet published advisory FG-IR-26-175 for CVE-2026-104286 on 1 October 2026. The US Cybersecurity and Infrastructure Security Agency added the vulnerability to its Known Exploited Vulnerabilities Catalog on the same day. The two notices make active exploitation, rather than theoretical exposure, the immediate basis for response.

At the cutoff, FortiMail 8.0.2, 7.6.7 and 7.4.9 were still described as upcoming fixed releases. Users of the affected 7.2 branch were directed towards a fixed release in the 7.4 branch or later. Administrators should check Fortinet’s current advisory before choosing an upgrade target because release availability can change quickly.

What the flaw can do

CVE-2026-104286 is an unauthenticated path traversal and improper null-byte handling issue in the FortiMail web interface. A crafted HTTP or HTTPS request can exploit those weaknesses to write arbitrary files to the appliance’s underlying system without authentication.

Fortinet assigned the flaw a CVSS v3.1 score of 9.8, Critical, and described the impact as execution of unauthorised code or commands. An arbitrary file write is important because it can become a route towards control of the mail gateway, rather than remaining a limited web interface defect.

watchTowr assessed that the file-write capability could lead to command execution and control of the gateway, potentially exposing stored mail, credentials and connected systems. That is a possible consequence of appliance control, not evidence that those outcomes occurred in the exploitation reported so far.

The reviewed public sources do not establish whether attackers accessed or removed data. They also do not identify a responsible actor, a victim count or location, the date exploitation began, or whether every observed attempt achieved command execution.

Affected branches and planned fixes

Fortinet’s advisory identifies four affected ranges, with no basis in the supplied evidence for expanding them.

For FortiMail 8.0, versions 8.0.0 through 8.0.1 are affected, and 8.0.2 or later was identified as the corrective release. For FortiMail 7.6, the affected range is 7.6.0 through 7.6.6, with 7.6.7 or later identified as the fix. Both corrective builds remained upcoming at the cutoff.

For FortiMail 7.4, versions 7.4.0 through 7.4.8 are affected, with 7.4.9 or later named as the correction. The affected FortiMail 7.2 range is 7.2.0 through 7.2.9. Fortinet did not list an in-branch correction and instead directed users towards a fixed 7.4 or later release.

An indexed copy of the machine-readable CVE record contains conflicting affected-version and solution entries, including references to FortiMail 7.0 and different fix numbers. Those entries should not be used to expand the scope or identify a safe version. At the evidence cutoff, the Fortinet advisory, corroborated by the Canadian Centre for Cyber Security notice, supplied the supported version guidance.

Containment and retrospective checks

Because fixed builds had not been confirmed as available at the cutoff, the immediate response was not a routine patch deployment. Fortinet published two principal workarounds: disable Identity-Based Encryption support, or remove public internet access to the FortiMail management interface and limit it to trusted private networks.

Administrators should assess the operational effect of disabling Identity-Based Encryption before applying that control. It can affect normal encrypted-message workflows. Restricting management access can also affect established administrative workflows, but it reduces public reachability while corrective releases are pending.

Running an affected version does not prove an appliance was reachable or compromised. Internet reachability of the interface and whether Identity-Based Encryption is enabled are practical triage factors, but neither condition alone demonstrates successful exploitation. Fortinet has not published a complete exploit chain or data showing how common those configurations are.

Applying a workaround also cannot show that an appliance was safe before containment. Fortinet published indicators of compromise covering files, log activity and network addresses. Organisations should preserve relevant logs and system evidence, then compare affected appliances with those indicators for signs of earlier exploitation.

An appliance with credible indicators requires an incident response assessment rather than being treated as resolved simply because management access has since been restricted. Conversely, a vulnerable version number on its own is not proof that exploitation succeeded.

The CISA deadline and Australian relevance

CISA set a 4 October 2026 remediation date for covered US federal civilian agencies. That date is not a universal deadline for private organisations, overseas operators or other public bodies. Inclusion in the agency’s exploited-vulnerability catalogue still provides a useful prioritisation signal for other defenders.

Australian organisations using the affected branches face the same product-level risk and can apply the same vendor guidance. The reviewed sources did not identify an Australian victim or a separate Australian government notice. CISA’s date should therefore not be presented as an Australian requirement.

The response has two distinct tracks. Operators need to reduce current exposure using current vendor guidance, while preserving and reviewing evidence for earlier activity. That separation matters because active exploitation and the technical possibility of arbitrary file writes are confirmed, while campaign scope, individual appliance takeover and data theft remain unconfirmed.

Changing an appliance's network reachability cannot establish whether earlier activity amounted to compromise, so containment and retrospective assessment require different questions. Let that distinction guide your next study choice: The Hack Academy's online cybersecurity training programme lists networking and internet vulnerabilities, with self-paced learning and practical exercises alongside theory.