On October 1, 2026, Fortinet published advisory FG-IR-26-175 for CVE-2026-104286: an improper pathname restriction combined with improper NULL-byte handling in FortiMail that may allow an unauthenticated attacker to write arbitrary files via crafted HTTP or HTTPS requests. Fortinet rates it critical (CVSS 9.8) and states it has been exploited in the wild. The same day, CISA added the CVE to the Known Exploited Vulnerabilities catalog with a federal remediation due date of October 4, 2026. If your SaaS still terminates inbound mail on self-managed FortiMail — or a customer asks you to operate theirs — treat this as unfinished business even after the federal due date. Fixed builds landed in a solution update on October 5; Cloud tenants were remediated by Fortinet on October 5. On-prem and hybrid boxes still need an owner, a version check, and an IoC hunt.
What is affected — and what Fortinet named as fixed
FG-IR-26-175 lists FortiMail 8.0.0–8.0.1, 7.6.0–7.6.6, 7.4.0–7.4.8, and 7.2.0–7.2.9 as affected. The solution table after the October 5 update is branch-specific: upgrade 8.0 to 8.0.2 or above , 7.6 to 7.6.7 or above , 7.4 to 7.4.9 or above . The 7.2 branch does not get a same-train fix — Fortinet directs operators to move to branch 7.4 or above. FortiMail Cloud customers on Fortinet-managed firmware do not need a customer-side upgrade after the October 5 Cloud remediation, but you should still confirm the tenant version in the vendor console. Do not invent "we are fine because mail is behind VPN." The attack is unauthenticated web/HTTPS toward the FortiMail GUI/IBE surface. Internet-facing webmail and IBE are the obvious exposure; mistyped firewall allowlists and forgotten DMZ boxes are how KEV actors still win after the news cycle moves on.
Remediation order for a SaaS weekend
1. Inventory. List every FortiMail VM, appliance, and MSP-managed instance that touches production or customer mail. Capture exact build strings before you change anything. 2. Patch floor. Move each branch to the fixed build above. Schedule 7.2 migrations to 7.4.9+ as a hard project, not a hope — 7.2 also approaches end of support later in 2026 per vendor lifecycle pages, so stacking a dead branch on a KEV is dual risk. 3. Workaround while you wait. Disable IBE or restrict webmail to trusted networks. Document the temporary control so nobody "re-enables IBE for a partner demo" without noticing. 4. Hunt IoCs. Fortinet published indicators including remote IPs 79.141.169.187 and 45.129.0.192 , suspicious archive-account CLI adds (example account name archive234 in the advisory sample), IBE Base64 decode exceptions, and odd admin logout events. Diff archive accounts, remote destinations, and unexpected admin sessions before you wipe evidence with a rebuild. 5. Evidence pack. Record prior version, upgrade time, workaround window, and whether IoCs appeared. Enterprise buyers and cyber-insurance questionnaires increasingly ask for KEV response timelines on email infrastructure.
FortiMail KEV checklist (CVE-2026-104286 / FG-IR-26-175)
[ ] Inventory every FortiMail build (8.0 / 7.6 / 7.4 / 7.2 / Cloud)
[ ] Upgrade to 8.0.2+, 7.6.7+, or 7.4.9+; migrate 7.2 → 7.4+
[ ] If delayed: disable IBE + lock webmail off the internet
[ ] Hunt advisory IoCs (IPs, archive234-like accounts, IBE decode errors)
[ ] Rotate admin creds / review CLI history if compromise suspected
[ ] Customer note ready for MSP-managed mail gatewaysWhy founders should care beyond "security owns mail"
Email gateways sit in the trust path for password resets, invoice PDFs, and support threads. An arbitrary file write on that box is not a niche appliance ticket — it is a brand and contract event. Agencies and mid-market buyers already map vendor questionnaires to CISA KEV response times; "we outsource mail" is not an answer unless you can show the MSP's patched build and your shared-responsibility note. Also separate Cloud (vendor-patched October 5) from the forgotten lab FortiMail still NATed for a pilot customer. KEV actors automate; they do not skip hosts because your network diagram looked tidy in 2022.
Founder takeaway
CVE-2026-104286 is an actively exploited FortiMail arbitrary file-write flaw on CISA KEV since October 1, 2026. Upgrade to the fixed builds Fortinet named on October 5 (8.0.2 / 7.6.7 / 7.4.9), migrate off 7.2, disable IBE when you cannot patch immediately, and hunt the published IoCs before you declare the incident closed. SaaS teams that treat mail appliances as someone else's problem will learn that KEV deadlines do not care who owns the MX record on paper.
Where FortiMail hides in SaaS estates
FortiMail shows up as the corporate MX, as a customer-managed appliance your professional-services team still SSHs into, and as a lab VM someone NATed "temporarily" for a pilot two years ago. Cloud tenants Fortinet patched on October 5 are the easy case. The hard cases are MSP-shared boxes, HA pairs where only the primary got upgraded, and DR sites that still boot the vulnerable image. Also check adjacent products in the same management plane. Operators who finally patch FortiMail sometimes leave older Forti* appliances untouched — and October's broader Fortinet news cycle (including credential-theft campaigns against firewalls reported by law enforcement) is a reminder to treat vendor families as a program, not a one-CVE ticket.
Engineering owners: put FortiMail build strings into the same inventory system you use for Kubernetes node images. If it is not queryable, it will not be patched on a three-day KEV clock next time.
Customer and MSP communication
Send a short advisory with CVE id, FG-IR-26-175, fixed versions, and whether you observed advisory IoCs. If you are the MSP, state the maintenance window and whether IBE was disabled as a bridge. Silence reads as negligence when CISA's due date is already public.
Finally, rotate any admin credentials that might have been exposed if IoCs matched, and review whether the rogue archive-account pattern from Fortinet's samples appears in your config. Assume attackers wanted persistence, not only a one-shot write.
