FortiMail already exploited, patch still upcoming

The mail gateway is already being exploited. The patch is still upcoming.

Zaheer Ikbal, Founder, CyHelm

I would not sit on this one waiting for a patch note.

Fortinet published FG-IR-26-175 on 1 October. CVE-2026-104286. Someone who is not logged in can write files onto the FortiMail system through the GUI, over HTTP or HTTPS. They describe it as path traversal plus a null byte, score it 9.8, and say it is already being exploited. CISA added it to the KEV catalog the same day and flagged forensic triage under BOD 26-04.

That directive is for US federal civilian agencies. It does not apply to a company in the UAE. I still take one thing from it. If the bug is already in use and the box is on the internet, the later upgrade will not tell you whether anyone was in first.

Fortinet’s affected list:

  • 8.0.0 and 8.0.1. The fix is 8.0.2, and it is not out yet.
  • 7.6.0 through 7.6.6. The fix is 7.6.7, not out yet.
  • 7.4.0 through 7.4.8. The fix is 7.4.9, not out yet.
  • 7.2.0 through 7.2.9. They say move to the 7.4 branch or above.

That last line is the trap. 7.4.8 is still vulnerable, and 7.4.9 has not shipped. Moving a 7.2 gateway to 7.4.8 does not close this. Until a fixed build exists, you are on a temporary workaround, not the fix.

The CVE record was updated on 2 October and it disagrees with itself. The description matches Fortinet and never mentions 7.0. The version list on the same page is tighter, and then it adds 7.0.0 through 7.0.9, which Fortinet’s table does not have. The solutions text is worse. It tells you to upgrade to 8.0.1, 7.6.6, and 7.4.8. Fortinet still lists those as affected. It also tells you to upgrade FortiRecorder. Wrong product. Don’t take the fix from the CVE page. Use the PSIRT. If you still have a 7.0 box, don’t assume you are fine because the advisory skipped it. Ask Fortinet.

What I would do this week. Find every FortiMail, including the one nobody talks about because mail just works. Note the version, and whether webmail or the admin page is open to the internet.

Turn IBE off. In the GUI that is Encryption, then IBE, then IBE Service off. On the CLI it is config system encryption ibe, then set status disable, then end. If the business can’t drop IBE, take the webmail interface off the internet and leave it on a network you trust. If a web application firewall already sits in front, Fortinet’s other option is to block POST requests to /ibe that contain ../.

Look before anyone says it is handled. Fortinet published what they saw: 79[.]141.169.187 and 45[.]129.0.192, an archive account named archive234 aimed at that first address, an admin logout from a null interface, and encryption logs about an invalid Base64 character 0x2a plus failed logins for an internal user at your domain. Pull the logs and keep them. The upgrade will not rebuild that history for you.

Upgrade only to a build Fortinet names as the fix. Landing on another affected release is not patched.

Write down who turned the workaround on, when, and what the logs showed. If a customer or an insurer asks what you did before the patch existed, that note is the answer.

None of these sources names a UAE or GCC incident. That is not an all-clear. Check your own gateways.

Sources:

Leave a Comment

Your email address will not be published. Required fields are marked *