FortiMail CVE-2026-104286: A 9.8 File Write on the Appliance You Never Revisit

October 4, 2026 · 9 min read

FortiMail CVE-2026-104286: A 9.8 File Write on the Appliance You Never Revisit

TL;DR - CVE-2026-104286 is a CVSS 9.8 flaw in FortiMail that lets an unauthenticated attacker write arbitrary files to the appliance. Fortinet published its advisory in the same week the bug was found, and CISA added it to the Known Exploited Vulnerabilities catalog on 1 October 2026, which means it was already being used in the wild before the fix existed. The Hacker News and BleepingComputer covered it on 1 and 2 October. No regulatory deadline sits over an Australian business, but the exploitation is live, and a 9.8 that writes files without credentials is a whole-box problem. What you need to do: check whether your FortiMail admin interface is reachable from the internet, pull the affected versions and upgrade path from Fortinet's PSIRT advisory, patch inside your window, then hunt for compromise rather than assuming a clean patch closes the incident.


By The Numbers

ItemValue
CVECVE-2026-104286
Base scoreCVSS 9.8 (Critical)
Authentication requiredNone
What the attacker getsArbitrary file write
Added to CISA KEV1 October 2026
Exploitation at disclosureActive (zero-day)
Vendor advisoryFortinet PSIRT, same week
First coverageThe Hacker News and BleepingComputer, 1-2 October 2026

I spent last week doing annual reviews, which is the least glamorous security work there is, and in three of them I asked the same question: when was the mail gateway last patched? Three different answers, all of them shrugs. In one case the FortiMail box had been moved into a comms cupboard during an office fit-out and nobody had signed into its admin interface since the mail moved to Microsoft 365.

On 1 October 2026, CISA added CVE-2026-104286 to the Known Exploited Vulnerabilities catalog. It scores a CVSS 9.8, it needs no credentials, and it lets an attacker write files onto the appliance. Fortinet shipped an advisory the same week, and The Hacker News and BleepingComputer covered it on 1 and 2 October. The bug was being used before the patch existed, which is what a zero-day means and why it sits on a list called Known Exploited Vulnerabilities.

Here is the thing about a mail gateway specifically. It is the classic set-up-once appliance. It went in when the business left an old POP3 server, it stayed in front of Microsoft 365 or Google Workspace so the cloud tenant would stop getting flagged, and nobody has looked at it since because nothing was visibly broken. It is also the box on a trusted path. It sees every inbound message, it holds archives, it can rewrite rules, and it has local admin accounts on it.

Let me walk you through what the bug is, why a file write is worse than the score makes it sound, and the checks I would run tonight.


What CVE-2026-104286 actually is

In plain terms: without logging in, without a session, without a token, an attacker can cause FortiMail to write a file of their choosing to a path of their choosing.

That is the whole of it, and I am deliberately not listing affected builds here. The affected versions and the supported upgrade path live in Fortinet's PSIRT advisory, and they are the two things you must get exactly right. A wrong build number on a patch job is how a weekend becomes a Monday.

What matters is the shape of the flaw. Unauthenticated means the attack starts before any identity check, so MFA on your admin account is not a control here. A write primitive rather than a read one means the attacker's first move is to change the appliance, not read from it. Full stop.

A read bug tells you what the attacker saw. A write bug lets them decide what happens next. On an appliance that executes what it stores, that is the difference between an incident and a re-platform.

Why a file write on a mail gateway is a whole-box problem

Any system that stores a file it later executes is in trouble, because writing the file is the same as running it. Appliances are worse than ordinary servers for one reason: nobody logs into them with a terminal to look at the filesystem.

Can they take the box over? The configuration file is the obvious target. An overwrite that adds an admin account you did not create is a quiet, authenticated back door that survives your patch, which is why the hunting step later is not optional.

Can they make it mail you? A mail gateway is a trusted sender and a trusted relay, so content it modifies carries weight with finance teams in a way the same content from a random laptop would not. I have not seen a cited report saying mail was taken from breached FortiMail appliances and I will not imply otherwise. What I have is the primitive, and the primitive is enough for me to assume somebody read it.

Can they sit there quietly? There is no agent on a box in a cupboard, and if the logs are not forwarded, there may be no record of the entry at all.

What the KEV listing does and does not do for you

The catalog is a US federal list of flaws with confirmed active exploitation. Its main effect is a remediation deadline for US federal agencies, plus procurement language for everyone else. An Australian business has no legal deadline here, and nobody will fine you for a late patch.

So the comfortable thought is that it is someone else's problem. Two reasons to push back.

A KEV listing is a statement about volume, not intent. It means the flaw crossed from "a researcher has a proof of concept" into "somebody is doing this at scale against anyone they can reach". The regulator's calendar is not the deadline that matters. The attackers' calendar is.

And it is contractual. Plenty of MSP agreements carry a KEV or actively-exploited remediation SLA at 7, 14 or 30 days. A 1 October listing may have started a clock on you that your client will check. Pull the contract and look.

The exposure check, before the patch conversation

1. Test whether the admin interface is reachable from outside. Do not infer it from the firewall config, go and look. Have someone on a phone hotspot try it.

2. Check what else is exposed. SMTP, webmail, HTTPS on a management port. With no auth step to get past afterwards, exposure is the whole question.

3. Get your build and match it. Note the version in the console, take it to the PSIRT advisory, and confirm the upgrade path with Fortinet support.

4. Back up the configuration before you touch the firmware. A snapshot costs a minute and it is the only way to diff the config later.

5. If you cannot patch in the window, shrink the window. Management interface onto a VPN, admin access off the internet, relay allow-listed.

After the patch, hunt rather than assume

Patching closes the door. It does not tell you whether somebody walked through it while it was open.

  • Admin users. Can you produce the list of local admins as it was 30 days ago? If not, produce it now and start your baseline.
  • Files outside the expected set. Anything new, recently modified, absent from the vendor's file manifest.
  • Mail rules and transport maps. Filters and redirect rules you did not write. This is how a mail compromise turns into a financial one.
  • Scheduled tasks and scripts. If the platform runs them, a written file is a written script.
  • Outbound behaviour. Relay volume to destinations you do not send to. Your FortiMail should not be talking to strangers on your behalf.
  • Auth logs from the exposure window. If they are not forwarded anywhere, close that gap this quarter regardless.

None of this needs a tool you do not have. It needs logs, a config backup, and twenty minutes with a boring admin console.


The good news

This is an appliance patch. One vendor, one advisory, one box, applied in a maintenance window with a config backup in your pocket. There is no client fleet to roll out and no agent to deploy to three hundred machines. The advisory is public, the catalog entry is public, and the fix is available now. You are not waiting on anybody.

That it is on KEV rather than sitting quietly in a PSIRT feed nobody reads is the reason you are reading about it at all.

Key Takeaways

  • CVE-2026-104286 is a CVSS 9.8 unauthenticated arbitrary file write in FortiMail. No credentials, no session, remote.
  • CISA added it to KEV on 1 October 2026, and it was being exploited before the advisory landed.
  • No regulatory deadline applies in Australia. Active exploitation does not care about regulatory deadlines.
  • Check your contract for a KEV remediation SLA. A 1 October listing may already have started a clock.
  • Take versions and the upgrade path from Fortinet's PSIRT advisory. Config backup first.
  • A write primitive on a mail gateway is a takeover primitive. Patch, then hunt.
  • If you cannot produce your admin list and mail rules from 30 days ago, that is the real finding.

FAQ

What is CVE-2026-104286? A critical FortiMail flaw that lets an unauthenticated attacker write arbitrary files to the appliance. CVSS 9.8, added to the CISA KEV catalog on 1 October 2026.

I use Microsoft 365 or Google Workspace. Do I still need to patch FortiMail? If FortiMail is still in the mail path, yes. Gateways stay deployed as spam filtering, archiving, anti-phishing and relay layers long after primary mail moved to the cloud, and they sit in front of the tenant, not behind it.

Does the CISA KEV deadline apply to Australian businesses? No. The catalog sets deadlines for US federal agencies, and there is no equivalent legal deadline here. The flaw is confirmed as actively exploited, and MSP contracts often carry their own KEV SLA.

Which FortiMail versions are affected? The affected list and upgrade path are in Fortinet's PSIRT advisory for this CVE. Check your build against it and confirm the path with Fortinet support rather than jumping versions.

Has anyone confirmed data was stolen from compromised FortiMail appliances? I have not seen a cited report establishing that and I will not guess. The bug class is the reason to assume it is worth checking, and the checks are cheap.

My Take

The FortiMail box is not the problem. It is the symptom of a pattern I see in nearly every review: a device that was critical during a migration, is still doing that job years later, and has no named owner, no patch cadence and no log retention. This one will be patched, and in six months we will argue about the next one, which will find the same cupboard.

The thing I would push hardest on is the inventory. A one-page list of internet-facing appliances with owner, build and last-patched date is the cheapest control in this post, and it is the prerequisite for all the others. If you cannot tell a client what version your mail gateway runs, that is a worse position than being a week behind on a patch.

So patch tonight, hunt this week, then spend an hour building the list. The KEV catalog is free, public and updated constantly. It only helps people who already know what they own.

None of this is exciting. But it works.


Mathew Clark Founder, SecureInSeconds Currently: rewriting a client list of appliances that nobody owns, starting with the one in the cupboard Drafted with AI assistance, then fact-checked line by line by a human.


Further Reading

Share:
Buy me a coffee

You might also like