FortiMail Zero-Day: Disable IBE and Hunt

FortiMail Zero-Day: Disable IBE and Hunt

Fortinet published advisory FG-IR-26-175 on October 1, 2026 with a very short timeline — one line, initial publication — and no fix attached to most of the affected product lines. CVE-2026-104286 scores 9.8, needs no authentication and is already being exploited, the advisory and BleepingComputer. For three of the four affected FortiMail branches, the only thing on offer is a three-line CLI workaround.

That is the easy half of this story. The hard half is what the vendor's own indicator list tells you about the boxes that were already hit, and why applying the workaround to a compromised appliance changes nothing.

Two weaknesses, and why they were filed together

Fortinet's description is worth reading closely, because the two weakness classes only mean something in combination:

"An Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') [CWE-22] and Improper Neutralization of NULL Byte or NULL Character [CWE-158] vulnerability may allow an unauthenticated attacker to write arbitrary files on the underlying system via crafted HTTP or HTTPS requests."

Path traversal on its own is usually read-and-disclose. Arbitrary file write is not — it is a code execution primitive the moment the process can choose what it writes and where. The impact field in the advisory says exactly that: "Execute unauthorized code or commands."

The NULL byte half is what usually makes the traversal land. A path that passes a validation check as /data/attachments/report.pdf can be truncated to /data/attachments/report.pdf\0../../etc/cron.d/x at the C layer, so the validated string and the string the kernel opens are not the same string. Fortinet has not published a root-cause analysis, so treat that as the standard reading of the CWE-22-plus-CWE-158 pairing rather than a vendor-confirmed mechanism for FortiMail specifically.

The discoverer is named in the advisory's acknowledgement: Gwendal Guégniaud of Fortinet's Product Security team, found internally — which is why the disclosure timeline has exactly one entry.

The version table is the trap

Look at the last row. It is the only one with a target you can install today, and it is not a patch — it is a branch move. Everything on 7.4, 7.6 and 8.0 is waiting on a build that does not exist yet, which is the same version arithmetic trap that caught people in the MikroTik pre-auth RCE: a number that looks like a fix in one advisory means nothing if it came from a different flaw's fix table.

The workaround, and what it does not do

Fortinet's first mitigation is to switch off identity-based encryption:

config system encryption ibe
set status disable
end

IBE is the encrypted-message feature, and the advisory's log evidence points at that code path — one of the published signatures is an IBE media decryption failure, Invalid Base64 Encoding at pos 0. Character=0x2a. The second option is to remove the management interface from the internet entirely and limit it to trusted private networks.

Both are containment, not remediation. Disabling IBE stops the next request from working. It does not remove a file that is already sitting on your appliance, and it does not stop persistence that is already established from running on the next reboot.

Read the indicator list as a description of an implant

Fortinet published seven file indicators with SHA-256 hashes. The configuration of that list is the actual news:

/data/lib/liblog.so        ADDED
/bin/smit                  MODIFIED
/data/bin/webconsole       ADDED
/data/bin/mailservice      ADDED
/data/etc/httpd.conf       MODIFIED
/data/etc/ld.so.preload    ADDED
/data/migadmin.tar.gz      MODIFIED

/data/etc/ld.so.preload being added is the finding that matters most. That file is the dynamic linker's global preload list: an entry there is mapped into every process the loader starts. Paired with an attacker-supplied liblog.so sitting next to it, that is a library-preload hijack — code that attaches to the box's processes rather than living in one of them, which is why it survives deleting a single "malicious binary".

The two ADDED files under /data/bin/ are named to blend in. webconsole and mailservice are plausible FortiMail component names; a shared object called liblog.so is the most plausible library name on the system. The /data/migadmin.tar.gz modification plus a cron entry from the log — (root) CMD (/bin/sh -c 'O=/migadmin ... — is root-level persistence that re-establishes itself after the reboot you were planning to do as part of patching.

Read together: a persistent, preloaded implant with root persistence, not a stray webshell. If those paths exist, the box is compromised, and "apply the workaround" is not the end of the incident.

The archive account tells you what they wanted next

The most revealing log line is a configuration change, not an attack:

msg="Added 'archive234' to 'archive account' : rotation-size[50]
rotation-time[1] rotation-hour[14] destination[remote]
remote-ip[79.141.169.187] remote-username[archive234]
remote-password[***] remote-directory[/uploads] (user: admin, from: cli)"

The attacker did not exfiltrate with their own tooling. They used the mail gateway's built-in archive and retention feature, configured from the CLI, to ship archived mail to a server they control. 79.141.169.187 is not just the destination in that config line — it is also the first of the two IP addresses in Fortinet's own indicator list, alongside 45.129.0.192.

The (user: admin, from: cli) attribution is worth flagging honestly: this says the action was performed by an administrator account from the CLI. Fortinet has not said whether that means stolen credentials or post-exploitation escalation from the file-write primitive. Either way, a remote unauthenticated file write turning into an authenticated admin action is the part of this incident that deserves the most attention.

A read-only triage script

The indicators are simple enough to check directly. This is deliberately read-only — it changes nothing and restarts nothing, so you can run it before you decide what your next move is:

#!/usr/bin/env bash
# CVE-2026-104286 - read-only FortiMail triage.
# Run on the appliance over SSH. Makes no changes and restarts nothing.
# IoCs transcribed from Fortinet PSIRT FG-IR-26-175 (published 1 Oct 2026).
# Adjust LOGFILE to wherever your FortiMail writes its event log.
LOGFILE="${LOGFILE:-/var/log/maillog}"

declare -A IOC_SHA=(
  ["/data/lib/liblog.so"]="8015f34dc84922b03688399d7f9fe7a00361789f7e420c7e2a2cdb23e75cef84"
  ["/bin/smit"]="77324ac428bde86d351fc5fc06f6d64a6bfe737dfb2743df1d4c5ac2418a5b6a"
  ["/data/bin/webconsole"]="7a6cea9f5c9e2e9994d4e3c4da73f86cf5acd05ea5d312c066c9d1dafd69ee38"
  ["/data/bin/mailservice"]="4000276a150a165d3c2537d1e19fb393c4de8333076a16655e28059cae82157b"
  ["/data/etc/httpd.conf"]="703e97c64e61e41dc3aaba580d82bb2aa7b6a11b54ee6fb467ed5d5a3bffdef5"
  ["/data/etc/ld.so.preload"]="8953ec7960b09f544a880b072ad4e6cfda7a8303f486251d3478dcfdfbac23b6"
  ["/data/migadmin.tar.gz"]="d6fe51c22b91776f4c961ea58bcac5917f15d560a619d7ce726d3d51795609d3"
)

echo "== 1. Indicator files =="
for f in "${!IOC_SHA[@]}"; do
  if [ ! -e "$f" ]; then
    printf 'absent  %s\n' "$f"
    continue
  fi
  got=$(sha256sum "$f" | cut -d' ' -f1)
  if [ "$got" = "${IOC_SHA[$f]}" ]; then
    printf 'MATCH   %s\n' "$f"
  else
    printf 'DIFFERS %s  (present, hash is not the published IoC)\n' "$f"
  fi
done

echo
echo "== 2. Attribution IPs in the event log =="
for ip in 79.141.169.187 45.129.0.192; do
  n=$(grep -cF "$ip" "$LOGFILE" 2>/dev/null) || true
  printf '%-16s %s hit(s)\n' "$ip" "${n:-0}"
done

echo
echo "== 3. Fortinet's published log signatures =="
grep -E 'archive234|/migadmin|Invalid Base64 Encoding' "$LOGFILE" 2>/dev/null | tail -20

If line 2 returns hits, you have the attacker's staging configuration in your own config. If /data/etc/ld.so.preload exists at all, treat the appliance as compromised rather than pending.

What to do, and in what order

Hunt before you patch. CISA added CVE-2026-104286 to the Known Exploited Vulnerabilities catalog on October 1 with a due date of October 4 — three days — and the entry carries a "Forensics Triage: Yes" flag alongside its BOD 26-04 guidance. That combination is the same patch-versus-evidence tension covered in the NetScaler zero-days, now sitting in a catalog row rather than an advisory. Capture logs and the indicator files before the upgrade cycle destroys them.

Read the required action, because it is unusual. The KEV entry tells agencies to apply vendor mitigations and follow the Forensics Triage Requirements — and then, for cases where mitigations are unavailable, to "discontinue use of the product if mitigations are unavailable". For a product with no patch on three of four branches, that is not a hypothetical.

Isolate the management interface now, then apply the IBE workaround if you cannot wait for 7.4.9, 7.6.7 or 8.0.2. If you are on 7.2, moving to the 7.4 branch is a real fix today.

Assume the mail passed through the box is in scope. FortiMail proxies every message your organisation sends and receives. A preloaded library on that appliance is a different proposition from an arbitrary file write on a developer laptop, and it deserves a correspondingly wider assessment.

Do not wait for an actor name. Fortinet has not disclosed when the flaw was first exploited, how many systems were compromised, or who is behind the attacks. It says it is communicating with government agencies including CISA, and the KEV entry records ransomware use as "Unknown". An internal pre-auth RCE that is actively exploited rarely resolves into a neat attribution story — treat it as opportunistic until proven otherwise.

Sources

• Fortinet PSIRT: FG-IR-26-175: Improper limitation of a pathname to a restricted directory
• CISA: Known Exploited Vulnerabilities Catalog (CVE-2026-104286 entry)
• BleepingComputer: Fortinet warns of critical FortiMail flaw exploited in zero-day attacks