FortiMail: patch out on the 2nd, advisory on the 7th, mitigation still on

On 1 October Fortinet published the kind of advisory that does not wait for your calendar: a 9.8 flaw in FortiMail, exploitable without credentials, already exploited and with no fixed release available. The only thing on the table was switching a feature off. The release notes for the fixed 7.6 build are dated 2 October; the advisory was not updated to say so until the 7th. Anyone watching the advisory, which is what everybody recommends, had the patch published five days before they found out. And the second half of the job —turning back on what was turned off— usually isn't written down anywhere.

Two dates on the same advisory

The file is FG-IR-26-175, published on 1 October 2026 and updated on the 7th. The vulnerability is CVE-2026-104286 and Fortinet describes it like this, verbatim: "An Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') [CWE-22] and Improper Neutralization of NULL Byte or NULL Character [CWE-158] vulnerability may allow an unauthenticated attacker to write arbitrary files on the underlying system via crafted HTTP or HTTPS requests". In plain English: anybody who can reach the appliance's web service can write files where they should not, without logging in. Score, 9.8 out of 10.

Two details you should not skip. First: it was found by Fortinet's own product security team —the credit goes to Gwendal Guégniaud— and the vendor still acknowledges it was already being exploited. Second: CISA added it to its known exploited vulnerabilities catalogue on 1 October itself, with a 4 October deadline for US federal civilian agencies. You are not a US federal agency, but that catalogue is the best public thermometer there is for "this is being used right now".

On 1 October those three numbers —8.0.2, 7.6.7 and 7.4.9— were already written in the advisory, with a note saying they had not been released yet. A file can name the version that will save you before you can download it.

It also works the other way round, which is the figure this post is built on. The change log in FortiMail's release notes reads 2026-10-02 — Initial release of the FortiMail 7.6.7 Release Notes (build 858), and 8.0.2 is dated 3 October (build 263). The advisory was not updated to acknowledge them until the 7th. Five days and four days of lag, respectively, between the patch being downloadable and the file you watch saying so. If your condition for removing a mitigation is "when the advisory says there is a patch", your clock runs behind Fortinet's.

The workaround switches off a business function

What Fortinet offered while there was no patch is in the file itself: "Disable the IBE feature support via the GUI (Encryption -> IBE -> IBE Service 'off')", or from the command line config system encryption ibe → set status disable → end. As alternatives, remove internet access to the webmail interface —or limit it to a trusted private network only— or block POST requests to /ibe containing ../ at a WAF.

IBE is identity-based encryption, and FortiMail's documentation explains what it is for without needing interpretation. When an outbound message matches an encryption policy, the appliance encrypts it by itself. The recipient gets a notification with an HTML attachment containing instructions and links; the first time, they register with the FortiMail, otherwise they log in and read it there, and the message is decrypted when opened. They install nothing and generate no keys. In office terms: it is the channel a company uses to send confidential documents to somebody outside its domain. A quote, a report, a payslip, a contract.

There are two things we will not assert, because the public documentation does not settle them and we are not going to invent an answer. One: what happens to notifications already sent whose recipient had not yet entered the portal. Two: what the appliance does with a message matching an encryption policy while the IBE service is off —whether it goes out in the clear, is rejected, or is held—. Both depend on your version and your configuration, and both are the first thing we would check on your box. If you switched IBE off last week and have not looked at this, look at it today.

The other two mitigations are not free either. Cutting internet access to the webmail switches off, along the way, the webmail somebody may be using. And a WAF rule blocking ../ inside a POST to /ibe is a reasonable guess about the shape of the attack as known today: good enough to get through a weekend and little more.

Switching off is one person's call; switching back on is nobody's

Switching off is one person's action, taken in a hurry and without debate: an exploited 9.8 does not go to committee. Switching back on demands four things that, a week later, are no longer in anybody's head: knowing what exactly was switched off, knowing why, checking that the condition that justified it no longer holds, and having somebody verify that what comes back actually works. Four requirements and no owner. That is why the mitigation stays.

A week ago we wrote about the gap on the way in: hardly any patching policy has a written entry for "there is no patch", and we proposed a written exception that expires by itself after seven calendar days so that nobody leaves one open. That clause forces you to look again, but it does not say what to look at on the day. That is the gap on the way out: the date arrives, the patch exists, and nobody has written down what was switched off or how you check that it came back. The gap on the way in shows up immediately, because somebody asks what we do. This one never shows up, because it does not hurt: the system is secure, the ticket is closed, and a switched-off feature raises no alerts. It produces an email that never arrives.

And this is not a problem of careless people. In the reference study of large internet services, operator error was the leading cause of failures in two of the three services analysed, and configuration errors the largest category within it (Oppenheimer, Ganapathi and Patterson, USENIX 2003). An emergency mitigation is, by definition, a configuration change made by hand, in a hurry and outside the usual window: the category that causes the most outages and leaves the least trace.

The temporary mitigation record: six lines

We are not proposing a tool or a process with a name. We are proposing six lines written the same day, in the ticket you already have open, before you close it. They come filled in with this case so you can see it is not an empty form.

• What was switched off, with the exact command. "FortiMail IBE service, config system encryption ibe → set status disable → end, on 1-10-2026 at 18:40, by [name]." The exact command matters because undoing it is not always the same command in reverse.
• What stops working and who notices. "The external recipient cannot read encrypted mail. Sales and admin notice; the service desk does not." If this line cannot be written, nobody knows what the feature was for, and that is a finding in itself.
• Why, with the identifier. "FG-IR-26-175 / CVE-2026-104286, 9.8, exploited, no fixed release on the day of the change." Without the identifier, in three months this is a disabled checkbox with no apparent reason, and nobody dares touch it.
• The exact condition that removes it. "When this unit runs the fixed release for its branch or above: 8.0.2, 7.6.7 or 7.4.9." A condition you check by looking at the appliance. "When the patch comes out" will not do, and this case shows why: the patch came out five days before the advisory said so.
• Who removes it and who verifies. Two different names. And verifying means sending a message that triggers the encryption policy to an external test address and reading it from outside, on your phone if need be.
• A review date, whether or not the condition is met. The same cadence as the risk exception we proposed last week: seven calendar days. If the patch is still not out, the record gets looked at anyway, if only to confirm in writing that the workaround is still the lesser evil.

The record has to live where somebody looks: the inventory, a ticket that stays open, an exceptions list reviewed monthly. It does not live in a group chat; it sinks in two days and nobody reads it again.

Two things the patch does not close

First, if your FortiMail is on the 7.2 branch: the advisory sends you to another branch. "Upgrade to branch 7.4 or above", it says. That is a major version change on the appliance all your mail passes through, with the testing that requires. Meanwhile the mitigation is all you have, and the record above becomes the only written explanation of why your encrypted mail has been off for weeks.

Second: if your appliance was reachable, the patch closes the door but does not undo what came in. This is a file write vulnerability, and what it leaves behind is a file, not a session that expires on its own. Fortinet published indicators of compromise, and published rather more than you usually get: two IP addresses (79.141.169.187 and 45.129.0.192), specific system event log entries —a cron command run as root, admin logout events and an archive account added pointing at that same IP— and encryption log errors from IBE decryption. It is worth knowing which of those lasts. The IPs, not long: changing IP costs an attacker far less than reviewing a filesystem costs you. The log entries hold up better, and that is where we would start. Neither is a certificate of cleanliness; we wrote that one up at length: patching is not cleaning.

What we would do, and what we would not

What we would do this week:

• Upgrade to 8.0.2, 7.6.7 or 7.4.9 depending on the branch, and check the version on the appliance, not in the ticket.
• Remove the mitigation with the end-to-end test described above, and record who ran it and when.
• Ask sales, admin and whoever sends documents to third parties whether anything looked odd between the 1st and today. That conversation usually returns more than any log.
• If the appliance was reachable from the internet, review files and scheduled tasks before calling it clean.
• Write the record for the other mitigations you are carrying. There is always more than one, and they are almost never in the same place.

What we would not do:

• Leave the WAF rule as the permanent fix. It was a workaround with an expiry date, and the date has passed.
• Call a mitigation removed because the box is ticked. The proof is an email that arrives and gets read.
• Switch IBE off again without first warning whoever sends the confidential material. Thirty seconds of warning saves three days of "it never arrived".
• Use this case to have a go at the vendor. It found the flaw in-house, published the workaround the same day and the fix six days later. That is doing it reasonably well; the gap this post is about is ours, not theirs.

The failure and the outage

We have been saying this for years and it is not going to change: the failure is inevitable, the outage is a design decision. The failure here was the CVE, and you did not decide it. The outage —a company that has gone days unable to send encrypted documents to its clients, and does not know it cannot— you do decide, on the day you switch something off without writing down who turns it back on. Same vulnerability, two opposite outcomes. What separates them fits in six lines of a ticket.

Sources and method (verified 9 October 2026): the verbatim description of the vulnerability (CWE-22 and CWE-158, unauthenticated file write over HTTP/HTTPS), the 9.8 score, the affected branches (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), the fixed releases 8.0.2, 7.6.7 and 7.4.9, the "Upgrade to branch 7.4 or above" instruction for the 7.2 branch, the workaround text ("Disable the IBE feature support via the GUI (Encryption -> IBE -> IBE Service 'off')" and the console commands), the alternatives of removing webmail access and blocking POSTs to /ibe containing "../", the indicators of compromise (the two IP addresses, the system event log entries and the encryption log errors), the credit for the finding to Gwendal Guégniaud of the Fortinet product security team (the «Acknowledgement» section), and the publication (1 Oct 2026) and update (7 Oct 2026) dates all come from Fortinet PSIRT advisory FG-IR-26-175. That the fixed releases were named but not available at initial publication, the "reported to be exploited in the wild" wording with no further detail, and the addition to CISA's known exploited vulnerabilities catalogue on 1 October with a 4 October federal deadline are in Help Net Security's coverage of 2 Oct 2026. How IBE works —policy-triggered encryption, a notification to the recipient with an HTML attachment containing instructions and links, registration the first time, login thereafter, decryption on opening, and no software to install or keys to generate— comes from FortiMail's administration documentation. The figure on the leading cause of outages in large services is from Oppenheimer, Ganapathi and Patterson, "Why Do Internet Services Fail, and What Can Be Done About It?", USENIX 2003. What we do not know: we could not determine from public documentation what happens to IBE notifications already sent whose recipient has not entered the portal, nor what the appliance does with a message matching an encryption policy while IBE is off; the post states both as open questions and asserts nothing either way. Nor do we know how many organisations applied the workaround or how many have already removed it: the claim that "the mitigation is still on" is our reading of the pattern, not a measured figure. We have not independently verified active exploitation: we rely on what Fortinet and CISA state. The dates of the fixed releases (FortiMail 7.6.7 release notes dated 2 October 2026, build 858, and 8.0.2 dated 3 October, build 263) come from the change log in Fortinet's documentation; the advisory update date (7 October) comes from FG-IR-26-175 itself, and the gap between the two is our own arithmetic over those two sources. For 7.4.9 we confirmed the build (630) but not its publication date, so we do not give it. The five days on the cover measure that documentary lag and NOT how long any particular system stayed switched off. Cover photograph: Process Water Building, TRA-605, detailed view of six valve handwheels in wall niche, Historic American Engineering Record (HAER ID-33-G-64), Library of Congress, public domain, via Wikimedia Commons.