Fortinet Urges FortiMail Workarounds Amid Active Attacks

Fortinet has confirmed active exploitation of a critical FortiMail vulnerability and is urging customers to apply a workaround. Its October 1 advisory identifies CVE-2026-104286, an unauthenticated file-write flaw with a 9.8 severity score. For organizations running the email security product, this is an immediate exposure check, not a reason to wait for the next routine maintenance cycle.

The distinction matters: an advisory about a theoretical weakness and an advisory about attacks already happening require different decisions. Administrators have protective steps available even though repaired releases are not yet listed as available. The immediate question is whether an organization can reduce exposure while it prepares for the patch, rather than waiting for the two tasks to become one.

Check the version, then the workaround

Fortinet lists these affected releases:

• FortiMail 8.0.0 through 8.0.1; fix listed as upcoming 8.0.2.
• FortiMail 7.6.0 through 7.6.6; fix listed as upcoming 7.6.7.
• FortiMail 7.4.0 through 7.4.8; fix listed as upcoming 7.4.9.
• FortiMail 7.2.0 through 7.2.9; migration to branch 7.4 or above is listed.

The vendor’s current workarounds are to disable IBE feature support, or remove internet access to the webmail interface or restrict it to trusted private networks. Fortinet also lists a WAF alternative: block POST requests to /ibe that contain '../'. The linked advisory supplies the IBE configuration command and current instructions. The advisory previously named the management interface; administrators who followed that wording should reassess webmail exposure rather than assume their earlier restriction is sufficient.

Read that version table carefully. Moving to a newer branch should not be mistaken for proving that the installed build is fixed, particularly while that branch’s remedy is still marked upcoming. Administrators should verify the exact release and its availability with Fortinet before treating an upgrade as the end of the response. TechInform has not tested the workaround or a repaired build.

Exposure and compromise are different questions

BleepingComputer’s reporting describes the vulnerability combining path traversal and null-character handling problems. Crafted HTTP or HTTPS requests can permit unauthorized file placement, with the reported impact extending to code or command execution. This is not described as an attack requiring an administrator’s password.

The original report highlighted vendor-provided file, network, and log indicators. As checked October 2, the live advisory lists network addresses and log events but no longer displays that file list. Use the current vendor advisory when reviewing indicators; removal alone does not establish that a previously listed indicator was invalid. One example records an archive account configured with a remote destination; BleepingComputer says that could indicate an attempt to send archived data elsewhere. That is an investigative lead, not proof that every vulnerable appliance has leaked mail.

Fortinet has not publicly identified the attackers, counted compromised systems, or established when exploitation began, according to the report. Asked for further details, the company directed readers to its advisory and said it was coordinating with agencies including CISA.

For an affected organization, we would separate the response into two questions: can the vulnerable surface still be reached, and is there evidence somebody already used it? Reducing exposure answers the first. It does not, by itself, answer the second. Equally, being on an affected version is not sufficient evidence to announce a breach. Communications to staff or customers should follow verified findings, with uncertainty stated plainly.

TINA’s view

The defensible priority is containment while establishing what happened. A team should not postpone an exposure decision simply because the full attacker story is missing. Nor should it assume that installing a future fix will settle questions about earlier access. Those are different jobs, and a useful response needs an owner for each.

The strongest counterargument is operational: disabling a feature or narrowing webmail access can disrupt established workflows. That makes a controlled change, with a documented owner and checks afterward, important. It does not make passive waiting the safer default when the vendor confirms exploitation. The right choice depends on the actual deployment, rather than a generic instruction to disconnect every mail system.

Our urgency assessment would change if Fortinet withdrew the exploitation finding or established narrower conditions that excluded a particular deployment. For now, the concrete signals to watch are fixed-build availability and findings from the organization’s own investigation. Verify the workaround, revisit the advisory, and do not confuse reduced exposure with a clean bill of health.