Fortinet published FG-IR-26-175 on 1 October 2026 for CVE-2026-104286, a 9.8 in FortiMail, and confirmed it is being exploited. CISA added it to the Known Exploited Vulnerabilities catalogue the same day, with a federal deadline of 4 October — three days.

The advisory describes two weaknesses, and the pairing is the whole story.

Two bugs that are harmless apart

The first is path traversal: the product does not properly limit a pathname to the directory it is supposed to stay in. The second is improper neutralisation of the null byte.

Either alone is usually survivable. Traversal that lands inside a restricted directory writes a file somewhere useless. A null-byte quirk in a string that is never used as a path is a curiosity.

Together they are an unauthenticated write anywhere. In Fortinet's words, the pair "may allow an unauthenticated attacker to write arbitrary files on the underlying system via crafted HTTP or HTTPS requests".

Why the null byte keeps doing this

The null byte is where two layers of the same system disagree about where a string ends.

A string in a managed language carries its own length, so a NUL inside it is just another character and the validation sees the whole path. The same string handed to a system call written in C ends at the first NUL, because that is what a C string is. So the check inspects one filename and the filesystem writes a different, shorter one.

That is how a check that reads a path ending in an expected, allowed extension can end up writing a file that stops before it, and the attacker chooses where the write lands.

The appliance this happens on

The reason a 9.8 here is worse than a 9.8 elsewhere is what FortiMail is. It is a mail gateway: a device whose job is to accept connections from strangers, on the internet, continuously. There is no configuration in which it is not reachable.

Fortinet's workarounds say the rest. Disable the IBE feature, which is the identity-based encryption portal that serves external recipients, or restrict management interface access to trusted networks. Both are ways of removing the parts a stranger can reach, which is an admission that reachability is the exposure.

One branch has nowhere to go

The fixed versions are 8.0.2 and later, 7.6.7 and later, and 7.4.9 and later.

The 7.2 branch, from 7.2.0 to 7.2.9, has no fix. Its users are told to move to a fixed branch, which is not a patch but a migration — a different change window, a different test cycle, and on a mail gateway, a different risk of losing mail flow while it happens.

That is the part worth planning for today rather than on the deadline. An organisation on 7.2 cannot comply by patching, and the workaround is what has to hold until the migration is done.

What a file write buys on a mail gateway

Arbitrary file write sounds narrower than remote code execution, and on this class of device the gap is thin.

A gateway runs a web interface for administration and for the encryption portal, so a file written into a web-reachable directory becomes code the next time somebody requests it. Where that is not available, the same primitive reaches the scheduled-task and startup files that a Unix system reads on a timer or at boot, which is execution with a wait attached.

What sits behind that is worse than a generic server. A mail gateway holds the transport rules, the authentication for the domains it relays for, the certificates, and the mail itself while it is being scanned. An attacker with write access can add a rule that quietly copies inbound mail, which is a wiretap that leaves the mail flowing normally and shows up in no user's mailbox.

That is the reason the catalogue entry carries a three-day clock rather than a longer one. The directive behind it sets the deadline from exposure and automatability, not from the score, and an internet-facing mail appliance with an unauthenticated one-request flaw is the worst combination it recognises.

What to do

  • Check your version first. If you are on 8.0, 7.6 or 7.4, patch to the fixed release. If you are on 7.2, plan the branch migration and apply the workaround now.
  • Disable IBE if you do not use it, and take the management interface off any network a stranger can reach. Both are in Fortinet's own guidance.
  • Treat an exposed appliance as compromised until checked. An arbitrary file write on a device like this is used to drop a web shell, so look for files that appeared in web-reachable directories, for configuration changes nobody made, and for new administrative accounts.
  • Rotate credentials and certificates the appliance holds if it was internet-facing before the patch. A file write is a foothold, and what it collects afterwards survives the fix.
  • Keep the evidence before you upgrade. The federal directive that sets this three-day clock asks for that explicitly on exposed assets, and it is sound advice outside government too.

What is not established

  • Who is exploiting it. Fortinet names no actor.
  • How many appliances have been compromised, as opposed to scanned.
  • When exploitation began, and whether it preceded the advisory.
  • Whether a fix for the 7.2 branch will be released at all.