Start with the job the box does. A FortiMail appliance reads a company's email before the company does — scanning it, checking it, deciding what gets through. This week, the thing doing the checking is the thing with the hole in it.
On October 1, 2026, Fortinet published advisory FG-IR-26-175. The subject: a zero-day in FortiMail, its email security gateway, under active exploitation. The flaw is tracked as CVE-2026-104286. Its CVSSv3 score is 9.8, about as bad as these numbers get. And exploitation isn't theoretical, because Fortinet says it has been reported in the wild.
Pause on what "no account needed" means here. No password. No login at all. An unauthenticated attacker can write arbitrary files onto the underlying system by sending crafted HTTP or HTTPS requests. That is the kind of access that can quietly turn a security appliance into someone else's machine — quietly being the operative word, because a box that has been turned does not announce it.
A request that walks out of its folder
The vulnerability pairs two weaknesses, and neither one sounds dramatic on its own. One is a path traversal flaw, CWE-22, where a file path escapes the directory it was supposed to stay inside. The other is improper handling of NULL bytes, CWE-158. Read separately, each is a defect. Stitched together, they let a request reach places on the system it should never touch.
That stitching is the story. Security controls tend to be built one check at a time, and a check that holds against one weakness can be walked around by pairing it with a second. The path says where a file may go. The NULL byte handling decides where the path effectively ends. When the two disagree, the request goes where the attacker wanted it to go.
Who found it? Fortinet's own Product Security team. The discovery is credited internally to Gwendal Guégniaud. That detail matters for what it says about the disclosure: this was not a researcher announcing a bug on a deadline, it was the vendor finding a flaw in its own product and publishing while the attacks were already under way.
The affected versions cover four release branches: FortiMail 8.0.0 through 8.0.1, 7.6.0 through 7.6.6, 7.4.0 through 7.4.8, and 7.2.0 through 7.2.9. Four branches is a wide net. If your appliance sits in any of those ranges, the working assumption has to be that it is exposed until you have done something about it — not that it might be, not that someone will get around to checking. Exposed, until acted on.
And here is the uncomfortable part. The fixes — versions 8.0.2, 7.6.7 and 7.4.9 — had not been released when the advisory went out. They are listed as upcoming. Anyone on the 7.2 branch is told to move up to 7.4 or above rather than wait for a 7.2 patch: there is no fix coming down it, and waiting on it is waiting for nothing.
There is a planning problem buried in that word "upcoming," too. A named fix version is a promise, not a product. Teams can schedule around it — but they cannot install it. Everything defenders do until those versions ship is damage limitation: turn the feature off, narrow the exposure, watch the logs. Useful work, all of it. None of it is the fix.
Washington gave it three days
The official reaction was not routine. CISA added CVE-2026-104286 to its Known Exploited Vulnerabilities catalog on October 1 and gave US federal civilian agencies until October 4, 2026, to address it. That is a three-day window. Read the window, not just the listing. Agencies get deadlines for catalog entries all the time; a deadline this short is the agency saying, in the plainest bureaucratic language it has, that this one cannot sit in a queue.
There is no virtual patch to hide behind either. So the choice, for now, is mitigation or exposure. Those really are the two items on the menu.
Fortinet's workaround is to switch off IBE, the identity-based encryption feature, from the command line: config system encryption ibe, then set status disable, then end. Three commands. The alternative is blunter but effective — take the management interface off the public internet, or restrict it to a trusted private network.
Neither option is free, and it is worth being honest about that. Turning a feature off is a change to how the appliance works, made on a deadline, under pressure. Pulling a management interface off the internet is the right call and also an admission: the interface was reachable in a way it perhaps never should have been. Appliances behind layered defenses have more room to breathe here. An internet-facing mail gateway does not — it was put on the boundary on purpose, because the boundary is where its job is.
The files that tell on an intruder
Now the part too many incident responses skip. Applying the workaround stops new exploitation. It says nothing — nothing at all — about whether someone already got in. Fortinet has published indicators for exactly that reason, and they are worth the ten minutes they take to check.
The advisory lists added files at /data/lib/liblog.so, /data/bin/webconsole, /data/bin/mailservice and /data/etc/ld.so.preload. It also flags changes to /bin/smit, /data/etc/httpd.conf and /data/migadmin.tar.gz, with MD5 and SHA-256 hashes so teams can compare what is on their boxes against what attackers have been seen leaving behind.
Look at those paths again, because they are not random litter. Writing files onto the underlying system of a security appliance means the attacker gets to decide what code the box trusts. A file dropped into /data/etc/ld.so.preload is a persistence trick: it influences which libraries programs load. New binaries under /data/bin, with names like webconsole and mailservice, are not Fortinet updates that anyone ordered. They are there because somebody put them there, and that somebody was not the vendor.
Why publish hashes at all? Because a file path can be argued with and a hash cannot. The MD5 and SHA-256 values tell you whether what you found matches what attackers have left behind, or merely shares a name with it. In a three-day window, that is the difference between a hunt that happens and one that gets postponed until it no longer matters.
Two IP addresses appear in the indicators: 79.141.169.187 and 45.129.0.192. One suspicious configuration log shows an archive account named archive234, set up to send archives to the first of those addresses under an /uploads directory. An archive account, created on a mail gateway, sending archives out — on a box whose entire purpose is handling other people's mail.
Other clues in the logs include root cron commands referencing /migadmin, an administrator logout with a null interface value, IBE decryption errors reporting invalid Base64 data, and failed internal-user logins. None of those entries proves compromise on its own. Together, they form a pattern worth chasing — the same kind of pattern-matching that modern detection teams lean on, as covered in our reporting on AI-driven SIEM and SOC automation. And the same discipline applies beyond the appliance itself: infrastructure this exposed is where the thinking behind resilience for critical infrastructure under state-sponsored pressure starts.
One caution from the coverage so far: this flaw should not be confused with CVE-2025-32756, an earlier Fortinet zero-day that touched FortiMail among other products and was confirmed exploited against FortiVoice. Different bug. Different fix list. Mixing the two up in a ticket queue helps nobody.
Mitigated is not the same as clean
What hasn't Fortinet said? Plenty, for now. The company has not shared when the attacks were first spotted, where they landed, how many systems were compromised, or who is behind them. That silence is common in the first days of a disclosure, but it leaves defenders working from the indicators alone. The indicators are good. They are also, by definition, a picture of what has been seen — not a guarantee about what has not.
To be fair to the process, Fortinet did the things vendors are supposed to do at disclosure: a concrete workaround, a named fix version for each branch, and indicators detailed enough for a small team to run a meaningful check without buying anything. The gaps are about the attacks themselves, not the paperwork: no timeline, no victim count, no attribution.
So the order of work writes itself. Disable IBE or pull the management interface off the internet today. Then go hunting through the file list and the logs. Then patch the moment 8.0.2, 7.6.7 or 7.4.9 actually ships, and check the advisory again before assuming your branch is covered — earlier builds inside an affected branch are still affected, a detail that trips up rushed upgrades the same way exposed interfaces do in our analysis of enterprise API security architecture.
What does a sensible weekend look like, then? First, reduce exposure: disable IBE with the three CLI commands, or get the management interface off the public internet and behind a trusted network. Second, preserve evidence before you clean anything — rebooting or rebuilding first destroys exactly the artefacts the indicator list asks you to look for. Third, hunt: compare the listed files against hashes, look for the archive234 configuration and outbound connections to the two named addresses, and review unexpected account changes. Fourth, patch properly when the fixed releases land, choosing the fixed build for your branch.
Organisations should also treat "we applied the workaround" and "we were not compromised" as two separate sentences, because they are. Closing public management access limits exposure from today onward. It establishes nothing about last week. That distinction — between stopping the bleeding and checking whether any blood was lost — is where rushed incident responses usually fail.
And the target selection is the point, in the end. A mail gateway sees every invoice, every password reset, every board paper and every legal thread that crosses the boundary. It also authenticates. It decrypts. It sits inside the trust perimeter precisely because it has to. An attacker who owns that layer doesn't need to phish anyone this week; they can watch, wait, and read. That is a worse day than a single mailbox compromise, and it is why a 9.8 with confirmed exploitation gets a three-day federal deadline instead of a routine patch Tuesday.
It is not the only network product under active attack: a Cisco SD-WAN Manager flaw is handing attackers admin access without a login. Unpatched edge devices are rarely the end goal; they are the quiet first step. That is the same tradecraft behind nation-state espionage groups harvesting encrypted traffic now to decrypt later, where patience matters more than noise. For the applications sitting behind that perimeter, runtime self-protection that stops memory exploits in-process is one of the few defenses that still works when the patch does not exist yet.
