Exploited FortiMail Flaw: the Clearest Trace Is a Mail Archive Account Pointed at the Attacker's Server

Exploited FortiMail Flaw: the Clearest Trace Is a Mail Archive Account Pointed at the Attacker's Server

On 1 October 2026 Fortinet published an advisory for a flaw in FortiMail, the email security gateway many companies place in front of their mailboxes to inspect incoming and outgoing mail. The flaw, CVE-2026-104286, is rated 9.8 out of 10, can be exploited by an attacker with no account and no password, and Fortinet says it is being exploited in the wild. The same day, Saudi Arabia's National Cybersecurity Authority issued alert 2026-7895 at Critical severity, and the US Cybersecurity and Infrastructure Security Agency (CISA) added it to its catalog of known exploited vulnerabilities.

Last week we wrote about an exploited flaw in Cisco's branch-network manager and the question of who patches the managed systems in your company. This one differs in a way that matters to management before IT: among the indicators of compromise Fortinet published is a log line showing the attacker added a mail archive account whose destination is an external server. The risk here does not stop at the appliance. It reaches the company's mail itself.

What Fortinet published

• Product: FortiMail, Fortinet's email security gateway.
• The flaw: a path traversal weakness combined with improper handling of NULL bytes in requests, which lets a crafted HTTP or HTTPS request write files onto the appliance's own system. Fortinet rates the impact as execution of unauthorized code or commands.
• Precondition: none. An unauthenticated remote attacker, with a CVSS score of 9.8 out of 10.
• Status: exploited in the wild according to Fortinet, and discovered internally by its own security team.
• The fix: when the advisory went out, no updates were available yet, and SecurityWeek reported on 2 October that fixes would come in upcoming versions with no release date given. Fortinet's release notes then date version 7.6.7 to 2 October and versions 7.4.9 and 8.0.2 to 3 October, and on 5 October Fortinet updated the solution section of the advisory. The fixed versions are in the table below.
• Local alert: National Cybersecurity Authority alert 2026-7895, dated 1 October 2026, Critical severity, recommending that affected products be updated.
• The US deadline: CISA gave US federal agencies until 4 October, three days, and made the flaw subject to its forensic triage requirements. It is the eighth Fortinet vulnerability the agency has added to its catalog since the start of 2026.

Affected and fixed versions, per the advisory:

Note the last row: branch 7.2 gets no fix within the branch. It needs a move to another branch, which takes planning but cannot wait.

Why the email gateway matters so much

The email gateway sits between the internet and your staff's mailboxes, so every incoming and outgoing message passes through it: quotations, supplier invoices, contracts, bank correspondence, and requests to change bank details. That is why it holds broad powers over mail. It is the system that inspects, quarantines, encrypts and archives messages.

The path the flaw exploits belongs to the IBE feature, identity-based encryption, which FortiMail uses to send encrypted messages that recipients open through a web portal. In many setups that portal is reachable from the internet so that recipients outside the company can use it.

The trace your team should look for: an archive account nobody created

Along with the advisory, Fortinet published indicators of compromise. They include two IP addresses, 79.141.169.187 and 45.129.0.192, and a system event log line showing an archive account named archive234 being added, with a remote server as its destination: the same address, 79.141.169.187, in a directory called /uploads. The same line shows the change was made under the username admin, from the command line.

To understand what that line means: FortiMail's archiving feature stores archived messages in archive accounts, and each account has a destination. It can be local, on the appliance's disk or a network storage server, or remote, on a server the appliance connects to over FTP or SFTP. Which messages get archived is decided by separate archiving policies. So an archive account pointed at the attacker's server becomes, once an archiving policy is attached to it, a route for copying messages out of the company. The advisory does not say whether any mail was actually copied in the cases found.

What to ask of your IT team or service provider:

• Review every archive account and archiving policy on the appliance, and ask about any remote destination nobody in the company recognizes.
• Search the logs for the two published addresses, and for an account named archive234 or any recent archive account whose creator is unknown.
• Review administrator accounts on the appliance and any configuration change nobody can account for.
• Save a copy of the logs and configuration before patching. Settings usually survive an upgrade, so an account added before it stays until someone deletes it. The patch closes the door. It does not tell you who came through it.

If you cannot patch tonight

Fortinet lists a workaround with three options:

• Disable the IBE feature in the GUI (Encryption, then IBE, then turn IBE Service off) or from the command line.
• Or block internet access to the FortiMail webmail interface, or limit it to a trusted private network.
• Or, if there is a web application firewall in front of the appliance, block POST requests to /ibe that contain ../ .

Disabling IBE stops encrypted delivery through that feature, so if a department depends on it, agree a temporary alternative with them. A workaround narrows who can reach the flaw. It does not replace the upgrade, and it does not remove the need to check what happened before it.

The real damage reaches finance weeks later

Copying mail is not the goal in itself. Anyone who reads your correspondence with suppliers learns who sends invoices, when, in what format, and which purchase orders are waiting for payment. That is exactly the material invoice-redirection fraud needs: a message that looks like it comes from the supplier, inside a real conversation, asking for the next payment to go to a new bank account.

Stopping this kind of fraud does not take technology. It takes a rule your finance team follows starting today:

• A supplier's bank account is never changed on the strength of an email alone, however genuine it looks.
• Verify by phone on a number already on the supplier's file, never a number given in the message itself.
• A change to a supplier's bank details needs approval from a second person other than the one who entered it, and the system records who changed it and when.
• The first payment to a new bank account gets a closer review than the rest.

We explained how to build the bank-detail change path into the system in our article on scheduled supplier payment runs and statement reconciliation.

If messages turn out to have been copied

If your team finds an unfamiliar archive account or evidence that messages were copied, treat it as a data breach, not a configuration mistake, because email usually carries personal data: customers' names, mobile numbers and addresses. SDAIA's procedural guide on personal data breach incidents requires the controller to notify the competent authority within 72 hours of becoming aware of an incident that may harm the data or the people it belongs to, or conflict with their rights or interests, and to notify affected data subjects without undue delay if it harms their data or conflicts with their rights or interests. Tell the suppliers and customers whose correspondence was exposed, too, because fraud messages carrying your company's name may reach them.

The Origami view

We build business systems. We do not sell or run email appliances. But every system we build sends email: invoices, order confirmations, account statements. In our view, the ability to copy company mail deserves the same scrutiny as access to the accounting system, because the invoice and the bank-detail change request both travel through email before they reach the system.

We read this flaw for Saudi business owners in two ways. First, security appliances themselves have become a recurring target, so the device you bought to protect your mail needs someone who follows its alerts and updates it like any other system. Second, the best answer to stolen correspondence is not only technical: a phone-verification rule in finance defeats fraud built on stolen mail, even if the breach is never discovered.

Takeaways

• If your company uses FortiMail, find out its version today and upgrade to 8.0.2, 7.6.7, 7.4.9 or later, and move branch 7.2 to 7.4 or later.
• Until the upgrade: disable IBE, or block internet access to the webmail interface.
• Review archive accounts and policies, search for the two published addresses, and save the logs before patching.
• Tell finance today: no change to a supplier's bank account without phone verification on a known number and a second approver.
• If copied messages contained personal data and the breach may harm the people concerned or conflict with their rights or interests, the deadline to notify the competent authority is 72 hours from becoming aware of the incident.

Sources

• Fortinet: advisory FG-IR-26-175 for CVE-2026-104286 (published 1 October 2026, updated 5 October), source of the versions, workaround and indicators of compromise
• National Cybersecurity Authority: Fortinet alert 2026-7895 (1 October 2026)
• CISA: one known exploited vulnerability added to the catalog (1 October 2026), and the catalog itself
• SecurityWeek: Exploited Fortinet FortiMail Zero-Day Calls for Urgent Action (2 October 2026)
• Fortinet: FortiMail Administration Guide, configuring email archiving accounts
• Fortinet: FortiMail release notes for 7.6.7, 7.4.9 and 8.0.2
• SDAIA: Personal Data Breach Incidents Procedural Guide