"CVE-2026-104286: FortiMail Zero-Day Path Traversal Exploited in the Wild"

CVE-2026-104286: FortiMail Zero-Day Path Traversal Exploited in the Wild

Verdict up front: if your organisation runs FortiMail, treat this as an assumed-breach incident, not a patching task. CVE-2026-104286 is a CVSS 9.8 unauthenticated arbitrary file write that was exploited before it was disclosed, CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on 1 October 2026 with a 4 October remediation deadline and mandatory forensic triage, and Fortinet's own advisory says "customers are urged to apply the workaround", because fixed builds (8.0.2, 7.6.7, 7.4.9) were listed as "upcoming" at publication. Patch when you can, but hunt for compromise now.

The mechanics: a path traversal with a NULL-byte twist

Fortinet's advisory FG-IR-26-175 describes the flaw as a combination of two weakness classes: improper limitation of a pathname to a restricted directory (CWE-22, path traversal) and improper neutralization of NULL bytes (CWE-158). The vulnerable component is the GUI backend that serves Identity Based Encryption (IBE), the feature that lets FortiMail decrypt email encrypted to individual users' identities.

The root cause is the classic file-write antipattern: user-controlled input is concatenated into a filesystem path that is then used as the destination for a write, without normalising and verifying that the resolved path stays inside an intended directory. A crafted HTTP or HTTPS request to the IBE endpoint supplies a filename containing directory traversal sequences, escaping the upload directory and pointing the write anywhere the service account can reach. The NULL-byte component is what makes it genuinely dangerous on a modern codebase: many language runtimes and wrappers truncate a C-style string at a NUL character, so a filename like ../../../tmp/evil.php%00.jpg passes a check that verifies the extension is .jpg while the filesystem layer writes evil.php. Neutralising or filtering NULs is one of those checks developers forget because the bug class has been "known" since the 2000s, but it keeps resurfacing wherever paths cross language boundaries.

The impact chain is worse than "arbitrary file write" sounds. FortiMail is a Linux appliance that sits on your email path. An unauthenticated attacker who can write files can:

• Drop a web shell into a path served by the appliance's HTTP daemon.
• Overwrite configuration, Fortinet's own IOCs show attackers modifying httpd.conf, which changes what the web server will execute or expose.
• Achieve persistence via ld.so.preload, writing a path into /etc/ld.so.preload makes Linux load an attacker-supplied shared object into every dynamically linked process on boot and on exec. This is one of the most durable Linux persistence tricks known, and it is exactly what Fortinet's IOC list shows being used.
• Stage tooling and exfiltration infrastructure, the observed campaign configured a remote archive destination pointing at attacker-controlled infrastructure, effectively turning the mail gateway into a data shuttle.

Because the write happens as the appliance's service account and the box is an email security gateway, a compromised FortiMail also gives an attacker visibility into mail flow, the ability to poison or read messages, and a trusted internal position, which is why ransomware operators love edge appliances of this class.

Affected versions and severity

Per the NVD entry and FG-IR-26-175:

Some version data includes the 7.0 branch (through 7.0.9) as affected, if you are running anything that old you are on the vulnerable side regardless. CVSS v3.1 is 9.8 Critical: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, network-reachable, no privileges, no user interaction, total impact. Fortinet rates the impact as "execute unauthorized code or commands" and confirms Known Exploited: Yes. Note the "Virtual Patch: No" line in the advisory: Fortinet is not shipping an IPS signature that closes the hole for you; the workaround below is on you.

Exploitation status

This is about as bad as exploitation status gets:

• Fortinet's advisory states it "has been reported to be exploited in the wild", vendor-confirmed, not researcher speculation.
• CISA added it to the KEV catalog on 1 October 2026 with a due date of 4 October, and flagged forensic triage required under Binding Operational Directive 26-04. That three-day clock with a triage mandate is CISA's way of saying: patching alone is not the assignment, because the box may already be owned.
• Belgium's CCB issued a matching urgent warning advising affected operators to rotate DKIM keys, update DNS records, and rebuild the appliances, an unusually strong posture for a single CVE, reflecting that the file-write primitive plus persistence IOCs imply full host compromise, not just a popped web page.

Detection: what to hunt for this week

Fortinet published concrete IOCs in FG-IR-26-175. Translated into grep-able and SIEM-ready logic:

Known attacker infrastructure (block and retro-hunt for connections):

79.141.169.187
45.129.0.192

System event log, attacker persistence via cron (drop this as a grep/Sigma-style match on FortiMail system events):

type=event subtype=system pri=debug user=system ui=cron msg="(root) CMD (/bin/sh -c 'O=/migadmin ...

Sigma-style logic: provider: fortimail AND type:event AND subtype:system AND msg contains "/bin/sh -c 'O=/migadmin", any cron entry referencing a shell one-liner under /migadmin is anomalous on a healthy appliance.

Config tampering, attacker-added remote archive destination. The observed campaign added an "archive account" shipping mail data to the attacker's IP. Hunt for:

Added 'archive' to 'archive account' ... destination[remote] ... remote-ip[...] remote-username[archive...]

Sigma-style: subtype:config AND user:admin AND module:unknown AND msg matches Added .* to 'archive account' AND destination[remote]. Legitimate archive-to-remote configs exist, so verify any hit against change records, but remote-username[archive234] and remote-ip[79.141.169.187] are straight from the IOC list.

Encryption log fingerprints of exploitation attempts (the IBE decrypter choking on malformed input):

FortiMail::IBE::DecrypterMediaIn ... 'Invalid Base64 Encoding at pos 0. Character=0x2a'
Internal user *@domain.tld failed to log in.

Sigma-style: msg contains DecrypterMediaIn AND Invalid Base64 Encoding AND Character=0x2a, that literal 0x2a (*) is the traversal/NULL-byte payload failing to parse, i.e. someone sending exploit input to your IBE endpoint even if the write failed.

Filesystem triage on the appliance itself (from Fortinet's IOC listing, via responder write-ups):

• Unexpected or modified binaries under /data and /bin.
• Any non-empty /etc/ld.so.preload, on a stock appliance this file should be empty or absent. Treat any entry as compromise until proven otherwise.
• Modified httpd.conf versus a known-good copy from an unpatched sibling or vendor documentation.
• New or altered cron entries referencing /migadmin.

Web/WAF layer: if you front FortiMail with a WAF, search request logs for POST requests to /ibe whose bodies or parameters contain ../ or encoded traversal (%2e%2e%2f, ..%2f, ..%00). That is the exploit shape, and it is what the vendor workaround blocks.

Patch guidance and the workaround

Fixed builds were not yet generally available when Fortinet published on 1 October (the advisory's own table says "Upgrade to upcoming 8.0.2 / 7.6.7 / 7.4.9"), so until your build lands, apply the vendor workaround, any one of:

1. Disable IBE via GUI (Encryption → IBE → IBE Service: off) or CLI:

config system encryption ibe
    set status disable
end

This removes the vulnerable code path entirely. If you do not actively use Identity Based Encryption, and most Australian deployments don't, this is the right call permanently, not just as a stopgap.

1. Restrict or remove internet access to the FortiMail webmail interface, allow it only from trusted private networks. The attack requires reaching the HTTP/HTTPS listener.

2. WAF rule: block POST requests to /ibe containing ../.

Then, once a fixed build is available: upgrade, and only then, because patching does not undo persistence, rebuild the appliance from scratch if triage found anything. A firmware reimage is the only trustworthy way to clear an ld.so.preload implant and its friends. Rotate all secrets the appliance held: DKIM signing keys (and update the corresponding DNS TXT records), admin credentials, SMTP authentication credentials, and any API keys stored on the box.

What Australian organisations should do this week

Email gateways are high-value targets everywhere, but the Australian context sharpens this one. FortiMail is widely deployed across Australian SMBs, schools, local government, and healthcare, exactly the sectors the ACSC keeps warning about edge-device compromise. If you're in one of the later Essential Eight maturity levels, ML3 explicitly assumes you can patch internet-facing infrastructure fast and detect compromise; this event is that assumption being tested.

1. Today: inventory. Find every FortiMail, including the forgotten one in a branch or a reseller-managed tenancy. If your exposure is unknown, assume the worst.
2. Today: apply the IBE disable or network restriction. Minutes matter; this is an unauthenticated, internet-reachable, actively exploited flaw.
3. This week: hunt, don't just patch. Run the log queries above over at least 90 days of retained FortiMail logs. Check /etc/ld.so.preload on every appliance. If you find cron entries, archive-account configs, or the IOC IPs, engage IR support and treat it as a reportable incident; under the Notifiable Data Breaches scheme, mail content exposure can trigger obligations within 30 days of awareness.
4. When fixed builds ship: upgrade, then rebuild if triage was inconclusive or positive. Rotate DKIM keys and admin credentials regardless, it is cheap insurance.
5. Structural fix: shrink your edge. Every internet-facing appliance is future CVE-2026-104286. Restrict management and webmail interfaces to VPN or private networks, keep IBE-class features off unless used, and make sure your Essential Eight patching and detection controls actually cover appliances, not just desktops. Our living-off-the-land detection guide pairs well with this one for teams building hunt capability.

For individuals: this one is organisational, unless you self-host a mail gateway, there is nothing to patch on your own devices. The takeaway for you is deliverability hygiene: organisations that compromised DKIM keys may have their legitimate mail suddenly fail or, worse, be spoofable. If a trusted Australian organisation's mail starts bouncing this month, that is plausibly this incident rippling outward, verify unusual requests by another channel.

This article is general information, not security advice for your specific environment.

Sources: Fortinet PSIRT advisory FG-IR-26-175, CISA KEV alert, 1 October 2026, NVD CVE-2026-104286, Belgian CCB advisory.

← All posts