FortiMail is being exploited. Fortinet's two affected-version lists disagree
CVE-2026-104286 allows unauthenticated arbitrary file writes and is in CISA's exploited catalogue. Fortinet's narrative and machine-readable version ranges do not match, while fixes remain listed as upcoming.
By Parminder Kumar Sharma · · 5 min read
The version check is part of the incident response
Fortinet says CVE-2026-104286 is being exploited. The flaw allows an unauthenticated attacker to write arbitrary files on a FortiMail system through crafted HTTP or HTTPS requests to the IBE interface. CISA added it to the Known Exploited Vulnerabilities catalogue on 1 October 2026. Fortinet scores it 9.8.
The urgent finding is in the records used to decide who is affected. Fortinet's prose names one set of version ranges; the structured affected-product field in its CVE record names another. The CVE description repeats the prose ranges, while the structured field adds 7.0 and stops earlier for several newer trains. Both are official data for the same vulnerability. An asset inventory that consumes only one field could reach a different conclusion from a person reading the bulletin.
Affected releases as published on 2 October. These are conflicting source entries, not a corrected version list.
| FortiMail train | Fortinet advisory prose / CVE description | Structured CVE affected field |
|---|---|---|
| 8.0 | 8.0.0 to 8.0.1 | 8.0.0 only |
| 7.6 | 7.6.0 to 7.6.6 | 7.6.0 to 7.6.5 |
| 7.4 | 7.4.0 to 7.4.8 | 7.4.0 to 7.4.6 |
| 7.2 | 7.2.0 to 7.2.9 | 7.2.0 to 7.2.9 |
| 7.0 | Not named | 7.0.0 to 7.0.9 |
What the observed artefacts can and cannot prove
An arbitrary write can alter a configuration file or place new code where a service will later use it. That is why the primitive is more consequential than a malformed web response. Fortinet's indicator list includes a loader configuration path and binaries, but its public bulletin does not document a step-by-step sequence from a particular HTTP request to each resulting artefact. The distinction matters when writing detection rules: match the vendor's indicators and local baselines, but do not invent a universal chain.
CISA's Known Exploited Vulnerabilities entry confirms exploitation has been reported. It is not a count of victims. The version discrepancy is a separate operational failure mode: automated inventory based on the narrower structured CVE ranges may miss 8.0.1, 7.6.6, or 7.4.7 to 7.4.8, while a prose-only process may miss the structured 7.0 entry. Compare the exact build against both official fields and keep a case open where they disagree.
A mail security product becomes a file-write path
Fortinet locates the flaw in the identity-based encryption (IBE) GUI. IBE lets a sender encrypt mail for a recipient identified by an email address, with access mediated through FortiMail. That makes the web-facing IBE flow a distinct exposure to inventory, rather than assuming that only the administrator's login page matters. The bulletin describes path traversal and improper handling of a NULL byte or character in crafted HTTP or HTTPS requests. The security boundary crossed is from an unauthenticated web request to a write at a file path on the appliance. The advisory does not publish a full exploit request or show every post-write action.
The vendor does publish concrete indicators. It lists additions including /data/lib/liblog.so, /data/bin/webconsole, /data/bin/mailservice and /data/etc/ld.so.preload, and modifications including /bin/smit, /data/etc/httpd.conf and /data/migadmin.tar.gz. These are investigation leads, not proof that every listed path appears on every compromised device. Its advisory also supplies hashes and attacker IP addresses. An operator should use the current vendor list directly, preserve evidence and look for correlated changes, rather than treating one absent file as clearance.
Fortinet lists fixed versions 8.0.2, 7.6.7 and 7.4.9 as upcoming in the checked advisory. That is not confirmation that an upgrade is available. For 7.2, the advisory points operators to 7.4 or later. Until an appropriate release is installed, Fortinet's workaround is to disable IBE, or restrict management access to a trusted private network. Confirm which access path a particular deployment exposes before relying on a network restriction.
What a FortiMail operator should do now
Take this with you
Ordered response
- Inventory every FortiMail appliance, including management and IBE exposure, and record its exact build.
- Treat the union of both official affected-version lists as requiring assessment until Fortinet reconciles the discrepancy.
- Apply Fortinet's documented workaround: disable IBE if it is not needed, or restrict management access to trusted private networks as the advisory directs.
- Review the appliance for unexplained file changes and other signs of compromise. Changing exposure does not erase an earlier file write.
- Track availability of the vendor's fixed releases and confirm the correct upgrade path for the deployed train before scheduling a change.
Sources
- PrimaryFG-IR-26-175 security advisoryFortinetaccessed 2026-10-02
- PrimaryCVE-2026-104286 recordCVE Programaccessed 2026-10-02
- PrimaryKnown Exploited Vulnerabilities catalogueCISAaccessed 2026-10-02
- PrimaryConfiguring IBE encryptionFortinetaccessed 2026-10-02
- Reported byFortiMail zero-day coverageThe Hacker Newsaccessed 2026-10-02
- Reported byFortiMail zero-day coverageBleepingComputeraccessed 2026-10-02
