What happened
On October 1, 2026, Fortinet disclosed CVE-2026-104286, a CVSS 9.8 FortiMail GUI path-traversal and null-byte neutralisation flaw that permits an unauthenticated attacker to write arbitrary files through crafted HTTP or HTTPS requests; Fortinet said exploitation had been reported in the wild.
The affected ranges 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 directed 7.2 users to branch 7.4 or later.
Fortinet listed FortiMail 8.0.2, 7.6.7 and 7.4.9 as upcoming fixed releases, so no generally available fixed build was identified for those branches in the cited weekend sources.
Fortinet’s published workaround is to disable Identity-Based Encryption by running config system encryption ibe, then set status disable, then end; management access should also be restricted to trusted networks. These changes reduce immediate exposure but do not establish that an appliance was not accessed before mitigation, and disabling Identity-Based Encryption can affect business workflows that require documented acceptance and restoration planning by the service owner. In the absence of a patch and fixed upgrade path, the cited source did not publish a generally available fixed build for affected FortiMail branches other than directing 7.2 users to a later branch. The workaround and management-plane restrictions are therefore interim controls, not evidence of closure. CISA added CVE-2026-104286 to the Known Exploited Vulnerabilities catalogue on October 1, 2026, set October 4, 2026 as the federal remediation deadline and required vendor mitigation plus forensic triage. The deadline elapsed during the weekend, making Monday assurance dependent on evidence collected from each appliance rather than a planned future change ticket. The cited sources did not publish the initial exploitation date, compromised-system count, exploit endpoint or responsible actor. Fortinet published these added-file SHA-256 indicators: /data/lib/liblog.so equals 8015f34dc84922b03688399d7f9fe7a00361789f7e420c7e2a2cdb23e75cef84; /data/bin/webconsole equals 7a6cea9f5c9e2e9994d4e3c4da73f86cf5acd05ea5d312c066c9d1dafd69ee38; /data/bin/mailservice equals 4000276a150a165d3c2537d1e19fb393c4de8333076a16655e28059cae82157b; and /data/etc/ld.so.preload equals 8953ec7960b09f544a880b072ad4e6cfda7a8303f486251d3478dcfdfbac23b6. Fortinet published these modified-file SHA-256 indicators: /bin/smit equals 77324ac428bde86d351fc5fc06f6d64a6bfe737dfb2743df1d4c5ac2418a5b6a; /data/etc/httpd.conf equals 703e97c64e61e41dc3aaba580d82bb2aa7b6a11b54ee6fb467ed5d5a3bffdef5; and /data/migadmin.tar.gz equals d6fe51c22b91776f4c961ea58bcac5917f15d560a619d7ce726d3d51795609d3. Fortinet also listed 79.141.169.187 and 45.129.0.192, a cron event invoking /migadmin, a CLI-added archive234 account pointing to 79.141.169.187 with remote directory /uploads, and an IBE BufferException reporting invalid Base64 at position 0.
Why this matters now
FortiMail sits in a privileged communications path, processing sensitive messages and frequently operating near identity, directory and administrative services. Arbitrary file write on that gateway can support persistence, credential collection, mail access or trusted-message abuse. The published artefacts show that observed activity progressed beyond scanning into modified binaries, preload persistence, web-server configuration changes and an outbound archive configuration.
The absence of generally available fixed builds for the 8.0, 7.6 and 7.4 branches changes the response model. Security leaders cannot define closure as successful patch installation. They need approved temporary controls, preserved evidence, explicit business acceptance for disabled functionality and a second change window when supported fixed releases become available.
The Sunday federal deadline is an urgency signal rather than proof that private-sector appliances are compromised. The leadership question for Monday is whether every exposed instance has received compromise assessment, not whether a vulnerability scanner has changed its status to mitigated. Provider-managed FortiMail must be included because outsourcing administration does not transfer evidence or disclosure risk.
The decision for security leaders
Treat every internet-reachable affected appliance as an investigation target until evidence supports a clean disposition. Assign messaging infrastructure, incident response and the relevant service owner together; a vulnerability-management ticket alone cannot resolve possible persistence on a security gateway.
Separate containment from restoration. Apply the IBE and access restrictions now where feasible, but retain a tracked exception for business processes that cannot tolerate the workaround. Pre-authorise expedited testing and deployment of FortiMail 8.0.2, 7.6.7 or 7.4.9 when Fortinet makes the applicable build available.
Require managed-service providers and hosting partners to return appliance-specific evidence: version, historical exposure, mitigation time, log-retention coverage, indicator results and any forensic limitations. A generic statement that the service has been patched or protected is not decision-grade assurance.
Evidence of closure
- Signed asset register identifies every FortiMail instance, owner, version and external exposure.
- Forensic report records indicator results, log coverage and evidence limitations for each appliance.
- Approved change records prove interim controls and subsequent installation of supported fixed builds.
- Incident disposition documents why each exposed appliance is clean, contained or escalated.
The Security.io assessment
The most material weekend fact is the collision between confirmed exploitation and the absence of generally available fixed builds for several current branches. That combination raises residual risk even where teams acted quickly, because successful mitigation does not reconstruct what happened before the control changed.
The published indicators are unusually useful but cannot prove absence of compromise. Attackers may use different infrastructure, remove artefacts or exploit the same primitive differently. Clean indicator results should therefore be combined with configuration history, management-access records, process and file review, outbound-connection evidence and explicit documentation of unavailable logs.
Attribution posture: Fortinet and CISA established active exploitation but named no threat actor, and the initial exploitation date remains unpublished.
Security.io assesses the immediate decision as high confidence because exploitation, affected versions, interim controls and forensic artefacts are supported by vendor and government sources. Campaign scale and data-access consequences remain unresolved, so any indicator match or unexplained appliance change should move directly into incident-response handling.
Questions for the morning meeting
- Which FortiMail gateways were reachable from untrusted networks before containment?
- Can available evidence distinguish a clean appliance from a mitigated but previously compromised appliance?
- Which business workflows depend on Identity-Based Encryption, and who accepts its temporary loss?