Table of contents
17
Read this in 30 seconds: CVE-2026-104286 is a CVSS 9.8 unauthenticated arbitrary file-write bug in Fortinet FortiMail, and Fortinet says it’s already being exploited.
- It lives in the one FortiMail feature built for people without an account. Identity-Based Encryption (IBE) exists so external recipients who’ve never logged into FortiMail can open encrypted mail through a web portal, and that portal is what’s broken.
- Fortinet found this chasing live attacks, not during a code audit. The advisory credits Fortinet’s own Product Security team and publishes a full list of files real attackers dropped on compromised boxes, not a theoretical proof of concept.
- The path to compromise is documented, not inferred. Fortinet’s own indicator list names a malicious
ld.so.preloadfile, two rewritten system binaries, two newly added ones, and two C2 IP addresses, pulled from real intrusions.- CISA flagged it for forensic triage, with a 3-day clock. Added to KEV on October 1, due October 4, meaning: check for prior compromise, don’t assume patching alone makes you safe.
- There’s a real workaround if you don’t use the feature. Disable IBE entirely, or restrict access to trusted networks, if you can’t patch today.
A feature designed to let strangers in without a password is exactly the kind of feature that becomes an unauthenticated attacker’s front door, if the path it hands them isn’t checked carefully enough.
CVE-2026-104286 hit Fortinet FortiMail on October 1, 2026, rated CVSS 9.8, and Fortinet’s own advisory states it’s being actively exploited. CISA added it to the Known Exploited Vulnerabilities catalog the same day, with a three-day remediation deadline and a forensic-triage flag, CISA’s way of saying this isn’t just a patch-it-and-move-on bug.
Here’s what CVE-2026-104286 actually is, the mechanism Fortinet’s evidence points to, what’s confirmed versus reconstructed, and the exact indicators to check your own FortiMail deployment against.
FortiMail is Fortinet’s secure email gateway, sitting in front of an organization’s mail flow to handle spam filtering, data-loss prevention, and encryption policy before messages reach an inbox. Identity-Based Encryption, IBE, is the piece of that product built for a specific, unavoidable problem: how does an external recipient, someone who has never had a FortiMail account and never will, open an email FortiMail encrypted on the way out?
The answer is a web portal that has to be reachable without a login, because requiring one would defeat the entire point. That’s not a design flaw by itself, plenty of products need an unauthenticated entry point for people outside the organization. CVE-2026-104286 lives inside exactly that portal. The flaw is in what it does with the request once it arrives: CVE-2026-104286 combines a path traversal weakness (CWE-22) with improper neutralization of a NULL byte or NULL character (CWE-158), and together they let an unauthenticated attacker write arbitrary files to the underlying filesystem via a crafted HTTP or HTTPS request.
An auth-bypass bug usually gets an attacker into an account. A write-anywhere bug on an internet-facing appliance gets them onto the filesystem directly, with no account involved at any point, which is a shorter and more dangerous path to full compromise.
Here’s Fortinet’s own description, from advisory FG-IR-26-175:
“Improper limitation of a pathname to a restricted directory (‘Path Traversal’) [CWE-22] and improper neutralization of null byte or NULL character [CWE-158] in FortiMail may allow an unauthenticated attacker to write arbitrary files on the underlying system via crafted HTTP or HTTPS requests.”
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:P/RL:O/RC:C, scored by Fortinet’s own PSIRT.Fortinet’s advisory confirms what CVE-2026-104286 does, an unauthenticated write to an arbitrary path, but doesn’t spell out the exact request format or the specific IBE handler involved. Based on how this CWE pairing works in practice, here’s the mechanism CVE-2026-104286 is almost certainly built from, labeled clearly as reconstruction, not confirmed Fortinet detail.
An IBE portal request that stores or retrieves message-related content typically takes some form of identifier, a message ID, an attachment reference, a key-exchange token, and uses it to build a file path on the backend. A path traversal bug means that identifier isn’t restricted to a safe character set: something like ../../../../data/etc/httpd.conf escapes whatever directory the application intended to confine it to.
The null byte half of the bug is usually there to defeat a check layered on top of the path-building logic. A common pattern in older C-based request handling is appending a fixed suffix to whatever the user supplied, something like .enc or .tmp, specifically so a traversal payload still ends up inside an expected file type.
A null byte (%00 in a URL, or a raw 0x00 byte in the request body) can truncate that string during low-level file operations despite passing a higher-level string-length or extension check, because the two layers disagree about where the string actually ends. The result: the attacker’s full traversal path, unmodified, reaches the file write, with no safe suffix appended after it.
/* Illustrative reconstruction of the vulnerability class CVE-2026-104286
* describes, not FortiMail's actual source. FortiOS firmware is closed-source;
* this shows the CWE-22 + CWE-158 pattern the advisory names, not a verified read. */
char path[PATH_MAX];
char suffix[] = ".enc";
/* user_ref comes straight from the IBE portal request, unsanitized */
snprintf(path, sizeof(path), "/data/ibe/store/%s%s", user_ref, suffix);
/* a null byte inside user_ref truncates the string here, at the libc level,
* even though the snprintf() call above already "added" the .enc suffix
* to what the higher-level validation checked */
FILE *f = fopen(path, "wb");
fwrite(request_body, 1, request_body_len, f);If user_ref is ../../../../data/etc/httpd.conf%00, the validation layer sees a string that ends in .enc, and the actual file operation, once the null byte truncates it at the libc level, opens /data/etc/httpd.conf for writing instead. That exact mechanism is our reconstruction of how a CWE-22/CWE-158 pairing like this one typically works, not something Fortinet’s advisory states directly, and we’re labeling it as reconstruction rather than confirmed fact.
What is confirmed, directly from Fortinet’s own IOC list, is that /data/etc/httpd.conf is one of the real files attackers modified in the wild. That’s not a coincidence with the mechanism above, it’s the kind of file a traversal-to-arbitrary-write bug would target precisely because overwriting the web server’s own configuration is a reliable way to regain access after the initial write.
This is the part of CVE-2026-104286 that sets it apart from most freshly disclosed CVEs: Fortinet isn’t publishing a theoretical severity score for CVE-2026-104286, it’s publishing forensic evidence pulled from systems attackers already compromised.
Fortinet’s advisory lists seven specific filesystem changes seen across real intrusions:
[ADDED] /data/lib/liblog.so[MODIFIED] /bin/smit[ADDED] /data/bin/webconsole[ADDED] /data/bin/mailservice[MODIFIED] /data/etc/httpd.conf[ADDED] /data/etc/ld.so.preload[MODIFIED] /data/migadmin.tar.gzTwo of those entries matter more than the rest for understanding how this becomes full remote code execution, not just a file sitting on disk. /data/etc/ld.so.preload is a dynamic linker configuration file: any shared object listed inside it gets loaded into every process that starts on the system afterward, a classic persistence and code-execution technique once an attacker can write to the filesystem at all. Pairing that with a modified httpd.conf and two new binaries dropped into /data/bin/ turns a single arbitrary-file-write primitive into durable, system-wide code execution, not a one-off file drop.
Fortinet also published two IP addresses tied to the campaigns it observed: 79.141.169.187 and 45.129.0.192.
CVE-2026-104286 isn’t happening in isolation for this vendor, and treating CVE-2026-104286 as a one-off would be a mistake. CVE-2026-24858, an authentication-bypass bug (CWE-288) affecting FortiAnalyzer, FortiManager, and FortiNAC-F, was added to CISA’s KEV catalog back in January 2026, also CVSS 9.8, also confirmed under active exploitation at the time.
That’s not a pattern we’re claiming goes deeper than what we directly verified, we checked this one CVE against NVD rather than repeating a count from secondary reporting, and we’re not asserting an exact tally of every Fortinet KEV entry this year. What it does establish is that an internet-facing Fortinet product with a critical, actively exploited bug reaching KEV isn’t a one-time event in 2026. If your environment runs Fortinet appliances at all, CVE-2026-104286 is a reason to check your whole fleet’s patch posture, not just the one box running FortiMail.
You’re exposed if both of these are true:
If you don’t use IBE at all, that second condition is the fastest thing to check, and the fastest thing to fix without waiting on a maintenance window.
Closing CVE-2026-104286 takes four steps, in this order:
config system encryption ibe, then set status disable, removes the vulnerable portal entirely if your organization doesn’t rely on it.Fortinet’s own IOC list gives you exact things to check for, not a general “look for suspicious activity” instruction:
# Check for the malicious ld.so.preload file Fortinet's advisory names
ls -la /data/etc/ld.so.preload
# Check for the two added binaries
ls -la /data/bin/webconsole /data/bin/mailservice /data/lib/liblog.so
# Confirm whether httpd.conf or migadmin.tar.gz match known-good hashes,
# or were modified outside your own change history
md5sum /data/etc/httpd.conf /data/migadmin.tar.gz /bin/smit
# Search connection logs for the two published C2 addresses
grep -E '79\.141\.169\.187|45\.129\.0\.192' /var/log/*What to check for CVE-2026-104286 specifically:
/data/etc/ld.so.preload at all. On a FortiMail system that hasn’t been compromised, this file shouldn’t exist. Its presence alone is a strong indicator, not a false positive to explain away./data/bin/webconsole or /data/bin/mailservice existing when your own change records don’t account for them. Fortinet lists both as added by attackers, not legitimate product files you’d expect to find there./bin/smit, /data/etc/httpd.conf, or /data/migadmin.tar.gz against whatever baseline or vendor-published hash you can compare against.79.141.169.187 or 45.129.0.192 in firewall, proxy, or NetFlow logs, regardless of how far back your retention goes.The part of CVE-2026-104286 worth testing for on your own deployments isn’t the specific ld.so.preload trick, it’s the broader pattern: the one feature a security appliance builds specifically to serve unauthenticated outsiders is, by necessity, the part of the product with the least room for a validation mistake, and the part most worth testing harder than anything behind a login.
Path traversal and null-byte-style sanitization gaps are also not new or exotic bug classes individually, which is exactly why they keep showing up in current-year advisories: a feature gets added, a filename or reference gets taken from user input, and the validation covering it gets tested against the obvious case, not every encoding and truncation trick an attacker would actually try. Our AI VAPT services methodology runs automated and human-led testing specifically against exposed, unauthenticated functionality like this, not just the authenticated surface most internal reviews focus on, because that’s consistently where bugs like CVE-2026-104286 live.
If you’re running any Fortinet appliance with an internet-facing component, our write-up on a similarly exposed F5 BIG-IP management interface covers the same underlying question from a different vendor: what’s actually reachable from outside, and does it match what you assume is reachable.
CVE-2026-104286 is a CVSS 9.8 vulnerability in Fortinet FortiMail combining path traversal (CWE-22) and improper NULL byte neutralization (CWE-158) in the Identity-Based Encryption (IBE) portal. It lets an unauthenticated attacker write arbitrary files to the underlying filesystem via a crafted HTTP or HTTPS request.
Yes. Fortinet’s advisory confirms active exploitation and publishes a detailed indicator-of-compromise list, including a malicious ld.so.preload file, modified system binaries, and two command-and-control IP addresses, from real intrusions. CISA added it to the Known Exploited Vulnerabilities catalog on October 1, 2026, with a remediation deadline of October 4.
FortiMail 8.0.0 through 8.0.1, 7.6.0 through 7.6.6, 7.4.0 through 7.4.8, and 7.2.0 through 7.2.9.
Yes. Disable the IBE feature (config system encryption ibe, set status disable) if your organization doesn’t use it. If you do use IBE and can’t patch immediately, restrict access to the portal to trusted networks.
Upgrade to FortiMail 8.0.2, 7.6.7, or 7.4.9. If you’re on the 7.2 branch, move to 7.4 or later, since there’s no 7.2.x patched build. Then check your system against Fortinet’s published indicators of compromise before assuming the patch alone addressed prior exposure.
No. CVE-2026-24858, an authentication bypass affecting FortiAnalyzer, FortiManager, and FortiNAC-F, was added to CISA’s KEV catalog in January 2026 under active exploitation, also at CVSS 9.8.
CVE-2026-104286 didn’t come from a routine audit, it came from Fortinet chasing activity that was already happening on customer systems, and the advisory reads like it: a specific list of files attackers dropped, specific IP addresses, a specific feature to disable if you don’t need it. That’s a different kind of urgency than a CVE disclosed ahead of any known exploitation.
Patch to the fixed build for your branch, disable IBE if you don’t rely on it, and run Fortinet’s own indicator checks against your FortiMail systems regardless of patch timeline. A clean patch today doesn’t tell you what happened before today.
Categories
Related articles
