Attackers are exploiting a path traversal flaw in Fortinet FortiMail, the company’s secure email gateway appliance. CISA added CVE-2026-104286 to its Known Exploited Vulnerabilities (KEV) catalog on 1 October, the day Fortinet published the CVE, and set a federal remediation date of 4 October. The complication for defenders is timing: Fortinet lists its fixed FortiMail releases as forthcoming, so for now the only protection is a workaround and tighter network access.
Unauthenticated file writes on a perimeter appliance
The weakness combines two classes CISA records against the entry: CWE-22, failing to keep a requested file path inside the directory it should be confined to, and CWE-158, mishandling a null byte embedded in input. Together they let a remote party who holds no account on the appliance place files of their choosing on the underlying operating system, using specially built web requests over HTTP or HTTPS.
Writing arbitrary files on a gateway is rarely the end of the story. Depending on where a file lands, it can alter configuration, plant a web shell or set up code that runs later, which is why Fortinet’s own problem-type entry in the CVE record describes the outcome as unauthorised code or command execution. Fortinet rates the issue 9.8 under CVSS 3.1, in the Critical band, with no privileges and no user interaction needed.
CISA’s SSVC entry in the same record matches that rating: exploitation active, the attack automatable, the technical impact total. Automatable and total together mean attackers can scan for reachable FortiMail interfaces and compromise them at volume rather than one by one.
What CISA and Fortinet have confirmed
- Exploitation in the wild. CISA added the flaw on evidence of active exploitation, and Fortinet’s advisory separately marks the flaw as exploited in the wild and tells customers to apply its workaround.
- A three-day federal deadline. Under Binding Operational Directive 26-04, a KEV entry earns a three-day window when the affected asset is publicly exposed, the flaw gives total control and exploitation can be automated. CISA’s due date of 4 October reflects that.
- A compromise check before the fix. The catalog flags the entry for forensic triage. CISA’s implementation guidance recommends that agencies scope affected systems within two hours, preserve volatile evidence such as memory before changing anything, then patch, contain, analyse for persistence and lateral movement, and reach an escalation decision within 48 to 72 hours. It frames those times as targets, not requirements.
- Ransomware connection unknown. CISA has not linked the flaw to ransomware campaigns in either direction.
None of the cited sources says who is behind the attacks, how many appliances have been compromised, or which sectors and regions are affected. No threat group has been attributed. Fortinet’s advisory does publish file hashes, IP addresses and log patterns linked to compromise; administrators should take those from the advisory itself.
Affected releases, and a record that disagrees with itself
Fortinet’s current advisory names four FortiMail branches as vulnerable:
| Branch | Vulnerable releases | Remediation per Fortinet |
|---|---|---|
| 8.0 | 8.0.0 to 8.0.1 | 8.0.2 or later, not yet released |
| 7.6 | 7.6.0 to 7.6.6 | 7.6.7 or later, not yet released |
| 7.4 | 7.4.0 to 7.4.8 | 7.4.9 or later, not yet released |
| 7.2 | 7.2.0 to 7.2.9 | Move to the 7.4 branch or newer |
The CVE record does not line up neatly with that table. Its structured version data ends lower on three branches (8.0.0, 7.6.5 and 7.4.6 rather than 8.0.1, 7.6.6 and 7.4.8), also lists the 7.0 branch (7.0.0 through 7.0.9) as affected, and its remediation text points to slightly different “upcoming” build numbers and to FortiRecorder releases that are not listed as affected at all. The safest reading for operators is to treat every FortiMail release on 7.0 through 8.0 as exposed until Fortinet ships builds and the record is corrected, and to watch the vendor advisory rather than either number set alone. Owners of FortiRecorder should check the advisory for whether their product is in scope.
Fortinet’s interim workaround is to switch off the appliance’s IBE (identity-based encryption) feature through the command line, or to limit the management interface to trusted networks. That the vendor’s first mitigation is disabling IBE suggests the vulnerable request handling sits in or near that feature, though Fortinet has not said so in those terms.
Priorities for FortiMail operators
- Inventory and expose-check. List every FortiMail appliance and virtual instance, including standby units, and confirm which of their web interfaces answer from the internet. Those come first.
- Preserve evidence before touching the box. Capture memory and logs off any internet-facing appliance before applying a workaround or later upgrade, so a compromise check is still possible afterwards.
- Apply the workaround now. Disable IBE if the business can do without it for now, and restrict management access to known administrative hosts either way. Neither step removes the flaw.
- Hunt with the vendor’s indicators. Compare appliance logs and file listings against the hashes, addresses and log patterns in the Fortinet advisory, and look for files on the system that no administrator placed there.
- Treat a hit as a mail-path incident. A compromised gateway sees inbound and outbound mail. Review routing and policy changes, audit administrator accounts, and rotate credentials, certificates and keys held on the appliance.
- Upgrade the moment fixed builds ship. Plan the change window now; 7.2 deployments need a branch migration rather than a point release.
Organisations outside the US federal government are not bound by the 4 October date, but the conditions that produced it — internet exposure, total impact, automation and confirmed attacks — apply to any exposed FortiMail. Other exploited Fortinet and email-gateway flaws are indexed in the CVE search.
Source: Cybersecurity and Infrastructure Security Agency (CISA)