FortiMail is due today. 7.6.7 notes closed CWE-22. PSIRT still says upcoming.

CVE-2026-104286's federal clock is 4 October. Release notes exist. The advisory CISA pointed at has not dropped upcoming.

RWP Ventures · 2026-10-04 · 15 min read · priority 9.0

The product is Fortinet FortiMail. The bug is unauthenticated arbitrary file write on the underlying system through crafted HTTP or HTTPS (CWE-22 path traversal plus CWE-158 NULL-byte handling). Fortinet’s CNA score remains 9.8 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Component is the GUI. Attack type is unauthenticated. Impact field is execute unauthorized code or commands. Virtual patch: No. Known Exploited: Yes.

Do not collapse four facts. They are not the same ticket.

1. The KEV clock is today. The PSIRT clock is not. FG-IR-26-175, retrieved 4 October ~10:00 UTC, still lists 8.0.2, 7.6.7, and 7.4.9 as upcoming. Timeline on that page is still 2026-10-01: Initial publication. A change ticket that says “upgrade to the fixed release” is still a wait if the operator’s source of truth is the advisory CISA linked.
2. 7.6.7 documentation exists. Fortinet’s FortiMail 7.6.7 release notes (mature, build 858, changelog 2026-10-02) say the build is no longer vulnerable to CWE-22. They list bug IDs 1303920, 1303439, 1348679, 1335851, 1336260, 1335852. They do not print CVE-2026-104286. CWE-22 closed in notes is not the same sentence as “this KEV row is patched.”
3. 7.4.9 and 8.0.2 are not a clean ship confirmation on this retrieval. 7.4.9 notes exist (mature, build 630); this retrieval did not surface a CWE table. The 8.0.2 notes URL is in the version picker; the body mixed 8.0.1 intro (feature release, build 257, changelog 2026-09-17) with a CWE-22 table in the same dump. Treat 8.0.2 as UNKNOWN pending a consistent vendor page, not as firmware in hand.
4. The workaround is still the close that exists. Disable IBE, or take the FortiMail webmail/management GUI off the internet / restrict it to a trusted network, or — on the live advisory — put a WAF in front and block POST requests to /ibe that contain ../. None of those evicts an attacker who already wrote files. BOD 26-04 still wants forensic triage before an image that does not yet appear on the PSIRT table.

Yesterday’s [2 October FortiMail assessment](/posts/2026-10-02-fortimail-cve-2026-104286-kev/) stands on the vulnerability. Today’s interrupt is the due date plus the notes / advisory split.

What happened

Thursday 1 October, Fortinet published FG-IR-26-175. Same day, CISA put CVE-2026-104286 on KEV with a 4 October due date. [Friday’s Daily Top](/posts/2026-10-02-fortimail-cve-2026-104286-kev/) recorded that the fixed builds were upcoming.

Saturday 3 October’s Zammad piece left that FortiMail clock running. This morning the catalog freeze is still 2026.10.02 / 1733. No new KEV row. The FortiMail due date arrived anyway.

Two vendor surfaces now disagree on whether a defender can install something.

Advisory (CISA’s notes URL): unauthenticated path traversal plus NULL-byte mishandling may allow arbitrary file write via crafted HTTP or HTTPS. “This has been reported to be exploited in the wild, customers are urged to apply the workaround below.” Solutions: upgrade to upcoming 8.0.2 / 7.6.7 / 7.4.9, or migrate 7.2.0–7.2.9 to the 7.4 branch or above — into a train whose own floor is still marked upcoming.

Workarounds on the live page:

config system encryption ibe
set status disable
end

Alternatively: disable internet access to the FortiMail webmail interface, or limit it to a trusted private network. Or if a WAF sits in front of FortiMail, block POST requests to /ibe that contain ../.

7.6.7 notes (2 October changelog): mature release, build 858. Common Vulnerabilities and Exposures section: FortiMail 7.6.7 is no longer vulnerable to listed CWE references, first among them CWE-22. Visit fortiguard.com/psirt for more information — the same PSIRT that still says upcoming.

That is a documentation event, not a PSIRT flip. RWP did not download a firmware image and will not invent a support-portal SKU.

7.4.9 / 8.0.2: 7.4.9 notes exist as a mature build 630 page. 8.0.2 is in the docs picker. Neither is a substitute for FG-IR-26-175 dropping the word upcoming.

CISA’s required action is unchanged: apply mitigations per vendor instructions, BOD 26-04, and forensic-triage language; discontinue use if mitigations are unavailable. Mitigations are published (IBE / GUI / WAF). Firmware on the advisory is not.

Why it matters

KEV due dates are not press-release decorations. For FCEB they are a BOD 26-04 clock. For everyone else they are the public “this one is being used” queue. Today that queue says FortiMail. The vendor page the catalog points at still will not let an operator close the row with a build number.

Three operational lies are in the ticket this morning.

1. “The due date means the ISO shipped.” False. Due dates are CISA’s. Ship dates are Fortinet’s. They did not move together. A notes page that closes CWE-22 without naming CVE-2026-104286, while the IR still says upcoming, is a reason to open a support case and ask which image is the KEV close — not a reason to mark the change ticket done from a browser tab.
2. “We will wait for PSIRT to flip, so we can skip the workaround.” Backwards. The workaround is what the advisory told customers to apply while builds were upcoming. That sentence is still on the page. IBE-off, GUI-off-the-internet, or WAF ../ on /ibe are the closes that exist. Waiting for a word to disappear from an HTML table is not a control.
3. “CWE-22 in 7.6.7 notes equals this CVE.” Unproven on this record. The notes list six bug IDs under CWE-22 and do not print CVE-2026-104286. Fortinet’s IR is still the CNA statement for the KEV row. Inventory and hunt against FG-IR-26-175. Treat 7.6.7 as a candidate floor, not as a forensic-triage waiver.

A FortiMail that journals industrial or safety-system mail is still an IT mail-gateway compromise until evidence shows process impact. None is in this record.

Who / what is affected

FortiGate, FortiOS SSL-VPN, FortiVoice, and FortiClient EMS are not this CVE.

Technical context

RWP is not reproducing request paths, NULL-byte encodings, or write locations. Fortinet’s published defender cut is enough: the GUI mishandles a pathname and a NULL; an unauthenticated HTTP or HTTPS request writes a file on the appliance. The live advisory’s extra WAF line names POST /ibe with ../ as the published filter, not as an exploit recipe.

What to hunt, from Fortinet’s published guidance — files, configs, and logs, not an exploit path:

• IBE still enabled on boxes whose management GUI is reachable from untrusted networks.
• Archive accounts that did not exist last week, especially names like archive234, remote destinations, or /uploads paths. The live advisory still shows a config add of archive234 with remote-ip[79.141.169.187], remote-directory[/uploads], from CLI as admin.
• Admin CLI sessions from (null), unexpected admin logouts, cron/debug lines touching /migadmin ((root) CMD (/bin/sh -c 'O=/migadmin ...).
• IBE decrypt exception: invalid Base64 at position 0, character 0x2a. Failed login for an internal user pattern *@domain.tld. A match is a lead. Fortinet did not say every IBE Base64 error is exploitation.
• Egress to 79.141.169.187 or 45.129.0.192 — and to any other new remote archive host. Two IPs are not a blocklist strategy.
• The seven paths and SHA-256 values recorded in [Friday’s assessment](/posts/2026-10-02-fortimail-cve-2026-104286-kev/) (/data/etc/ld.so.preload, /data/lib/liblog.so, /data/bin/webconsole, /data/bin/mailservice, /bin/smit, /data/etc/httpd.conf, /data/migadmin.tar.gz). The 4 October HTML retrieval of FG-IR-26-175 showed IPs and log lines; it did not reprint that file table. Absence from today’s HTML is not a clean bill. Keep hunting those paths.

ATT&CK mapping for the ticket, not a kill chain we ran:

No public proof-of-concept is in this assessment. We will not publish one.

Threat / exploitation status

Confidence on the KEV row, the due date, the still-upcoming PSIRT table, and the 7.6.7 notes CWE-22 line: high. Confidence that 7.6.7 is the CVE-2026-104286 close: moderate until PSIRT names it. Confidence on actor, victim count, and how far the file write was taken past persistence: low. Confidence that every FortiMail with IBE enabled is already compromised: low — reachability of the GUI is the precondition Fortinet described.

What defenders should do

1. Inventory every FortiMail — physical, VM, HA peer, lab, DR, hosted. Record the running version against FG-IR-26-175, not against a scanner CPE that still stops at 7.4.6 / 7.6.5, and not against a notes page that does not print the CVE. If you run 7.0, ask Fortinet.
2. Meet today’s KEV clock with the workaround that exists, then hunt. If the management GUI is reachable from an untrusted network, pull it behind a jump host today. If the estate does not need Identity-Based Encryption, disable it with the published CLI. If a WAF already fronts the GUI, add the published POST /ibe ../ deny. Document residual if IBE must stay on.
3. Preserve, then hunt, then constrain. Snapshot configs and logs off-box before you reboot or image. Check archive-account config. Check admin CLI from (null). Check the seven paths from Friday’s table even if today’s HTML omitted the hashes. BOD 26-04: a later ISO can destroy the evidence. Open a Fortinet support case with CVE-2026-104286 / FG-IR-26-175 in the title and ask, in writing, which image closes that CVE on your branch.
4. Do not close the KEV ticket from 7.6.7 notes alone. If support confirms a build and the support portal actually offers it, install it after the snapshot. Verify the running build number matches the image. 7.2 still does not get a 7.2.10 in this bulletin; the answer remains a branch move into 7.4, whose PSIRT floor is still upcoming.
5. If you find the IoCs: isolate the gateway, freeze mail-flow changes, rotate. Admin and operator passwords, API tokens, LDAP/SMTP credentials the box stores, archive-account secrets, and any trust downstream mail systems placed in that host. Rebuild from known-good firmware when Fortinet ships it on the IR. Do not “clean” ld.so.preload and return the box to MX duty.
6. Keep the rest of this window on the board. Zammad CVE-2026-102489 / CVE-2026-102490 are KEV, due tomorrow, 5 October. Cisco SD-WAN Manager CVE-2026-76504 was due yesterday, 3 October. NetScaler 88771/88772 were due 30 September. The mail gateway is today’s interrupt; those clocks did not pause.

RWP assessment

Score 9.0.

Highest-leverage development since yesterday’s Zammad hunt is not a new catalog row. It is the FortiMail KEV due date landing while the advisory CISA linked still says upcoming, and while Fortinet’s own 7.6.7 notes — dated 2 October, after Friday’s Daily Top — close CWE-22 without naming the CVE. That split is the operator problem: a BOD clock, a notes page, and an IR that have not been reconciled. Evidence quality is high on the catalog freeze, the IR text, and the 7.6.7 changelog (CISA JSON, FG-IR-26-175, Fortinet Document Library). Evidence quality is intentionally split on whether any image is the KEV close.

It outranks a second day on Zammad CVE-2026-102489 / 102490 because yesterday already assessed that session-to-root chain; the due date is tomorrow, not a new exploitation picture, and the vendor/researcher split on 490 has not moved on this retrieval. It outranks Cisco CVE-2026-76504 because that API bypass was Daily Top on 1 October; yesterday’s due date is now a missed clock, not a new finding. It outranks Microsoft Exchange CVE-2026-96940 (September 2026 V2 SU, KB5129955 family, 2–3 October) because Microsoft’s own exploitability table at publication said not exploited, publicly disclosed No, and the CVE is not on KEV. It outranks GitLab AI Gateway CVE-2026-90970 (CVSS 9.9, 2 October) because GitLab-hosted is already patched, the bug is authenticated Duo Agent Platform, and it is not on KEV. It outranks the 1 October CISA ICS batch because those advisories, as retrieved, did not claim in-the-wild exploitation.

What we are not saying: that 7.6.7 is confirmed to remediate CVE-2026-104286; that 8.0.2 or 7.4.9 have shipped; that a named APT owns this CVE; that ransomware is using it; that every IBE decrypt error is exploitation; that 7.0 is confirmed in or out; that a FortiMail journaling an industrial site is confirmed process impact; that disabling IBE remediates a box that already has ld.so.preload.

What we are watching

• Whether FG-IR-26-175 drops upcoming and names builds against CVE-2026-104286, including 7.0 / unlisted SKUs.
• Whether Fortinet support, CSAF/CVRF, or the firmware portal contradict the HTML table.
• Whether Fortinet or CISA names a cluster, a victim sector, or a post-exploit kit beyond the published IoCs.
• Whether the two published IPs grow into a longer C2 set, or stay as the archive/uploads pair.
• Zammad CVE-2026-102489 / 102490 due 5 October — [yesterday’s ticket](/posts/2026-10-03-zammad-cve-2026-102489-102490-kev/), still open.
• Whether a public PoC appears after a firmware exists. We will not publish one.

Sources

• Fortinet PSIRT — FG-IR-26-175 (CVE-2026-104286)
• Fortinet — FortiMail 7.6.7 release notes
• Fortinet — FortiMail 7.4.9 release notes
• Fortinet — FortiMail 8.0.2 release notes
• CISA — Adds one known exploited vulnerability (1 October 2026)
• CISA — KEV JSON catalog 2026.10.02
• CISA — Known Exploited Vulnerabilities Catalog
• CISA — BOD 26-04
• CVE-2026-104286 · NVD
• [RWP — FortiMail KEV Daily Top, 2 October 2026](/posts/2026-10-02-fortimail-cve-2026-104286-kev/)
• Microsoft — September 2026 V2 Exchange Server Security Updates
• MSRC — CVE-2026-96940
• GitLab — AI Gateway critical patch 19.2.4 / 19.3.2 / 19.4.1