Build1 publisher2 min readPublished
Patching FortiMail leaves the reboot-surviving ld.so.preload backdoor in place on exposed appliances
Fortinet confirmed a 9.8-rated, unauthenticated file-write zero-day in FortiMail that attackers are using to drop a reboot-surviving ld.so.preload rootkit. Patching closes the hole but leaves any implant already on the appliance in place.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- CISA added the flaw to its Known Exploited Vulnerabilities catalog on October 1 and set an October 4 deadline for federal agencies to remediate it.
- The write chains a CWE-22 path traversal with a CWE-158 NULL byte neutralization in the web management interface, and neither step needs a credential.
- The in-the-wild set drops webconsole and mailservice backdoor daemons alongside the loader rootkit and modifies smit, httpd.conf and the migadmin archive.
- A gateway that normally speaks only SMTP opening outbound web sessions is itself a compromise signal, whether or not the published C2 IPs appear in the logs.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A management interface that faced the network before patching means the appliance needs forensic triage, not just the update, before it can be trusted again.
- exposure FortiMail boxes on the 7.2 branch have no fixed build to install, so a team that reports itself current on 7.2.9 has no patch and stays exposed until it migrates.
- constraint Because liblog.so hides files, processes and connections from tools on the same box, a clean netstat or EDR result from the appliance proves nothing, and verification means imaging the disk off the device.
"Write a shared object, get it loaded, own every process on the box," is how the writeup's author described arbitrary file write on a Linux appliance [18]. The observed activity does exactly that. In the published indicators, the attacker adds an entry to /data/etc/ld.so.preload, and on a dynamically linked system every process loads whatever that file names before the program's own code runs [4]. That object, /data/lib/liblog.so, is a rootkit that can hide files, processes and connections from tools on the same box [5].
The flaw, which the writeup identifies as CVE-2026-104286, carries a CVSS vector that sets confidentiality, integrity and availability each to high, with low attack complexity and no privileges or user interaction required [10][19]. A patch closes the write path, but an implant already on disk stays where it is, and the author calls the usual "patch it" advice correct but insufficient [17]. "If your management interface was reachable before you patched, you have a hunt job, not just a patch job," the writeup's author wrote [15].
Read the version table before declaring yourself done. NVD lists 7.0.0 through 7.0.9 as affected, but the advisory does not enumerate a 7.0 branch, so a box on 7.0.x should be treated as affected and moved to a fixed 7.4 build [11].
On a healthy appliance, the author notes, /data/etc/ld.so.preload should be missing or empty. A non-empty file is the first thing to treat as compromise [13]. The published script checks that file, stats the known indicator paths, and greps live sessions for the two command-and-control addresses Fortinet listed, 79.141.169[.]187 and 45.129.0[.]192 [7]. The author says the script has not been run against a real FortiMail and that the paths should be verified on the appliance first [14]. One limit no script gets around: "A preload rootkit hides from the very processes it loads into," the author wrote [16].
What to watch
- Whether Fortinet or NVD updates the advisory table to list the 7.0 and 7.2 branches or ships a fixed 7.2 build.
- CISA compliance reporting or deadline changes tied to the October 4 KEV due date.
- Independent verification of the hunt script against a live FortiMail, which the author has not yet run.