Enterprise IT

Enterprise IT News: FortiMail Zero-Day Exploited, No Patch

Published October 2, 2026 · DNS Benchmark Pro Editorial · Reading time: 6 minutes

The most consequential enterprise IT news of the week is not a breach disclosure but a gap: a critical, actively exploited zero-day vulnerability in a security appliance that tens of thousands of organisations put directly on the internet, with no fixed firmware to deploy. Fortinet's FortiMail is a secure email gateway. It terminates inbound SMTP for the domains it protects, scans every message, and holds the credentials and policy that decide where mail goes next. Compromising one does not give an attacker a foothold on the edge of the network — it gives them the mail.

How the path traversal and null-byte bug works

Fortinet classifies CVE-2026-104286 under two weaknesses at once: CWE-22, improper limitation of a pathname to a restricted directory, and CWE-158, improper neutralization of null characters. That pairing is the whole story. The web tier validates a requested path, decides it is safe, and passes it down; a lower layer written in or bound to C then truncates the same string at the first null byte and resolves something else entirely. The two layers disagree about what file is being addressed, and the attacker chooses the disagreement.

The practical result, in Fortinet's words, is that an unauthenticated attacker "may be able to write arbitrary files on the underlying system via crafted HTTP or HTTPS requests." Arbitrary file write on an appliance running a predictable Linux userland is equivalent to remote code execution. You do not need a memory-corruption primitive when you can drop a shared object and have the loader run it for you.

The implicated feature appears to be Identity-Based Encryption, the portal FortiMail offers so external recipients can read encrypted mail through a browser. Fortinet's primary workaround is to turn IBE off, which is a strong hint about where the vulnerable handler lives. IBE is also, by design, reachable by anyone — it has to be, or the recipients it exists for could not use it.

Affected versions and the missing patch

Four release trains are affected, and the fixed builds for three of them had still not shipped when CISA's clock started. For anyone tracking enterprise IT news as an operational feed rather than a headline, that table is the whole advisory.

The flaw was found internally, by Gwendal Guegniaud of Fortinet's Product Security team, which usually indicates the vendor discovered the bug while investigating a live incident rather than in a scheduled audit. Fortinet has not said when exploitation began or how many appliances were hit.

Indicators of compromise worth hunting today

The detection section is where this advisory earns its place in the week's enterprise IT news. FG-IR-26-175 is unusually generous with detection detail, which is itself a signal: Fortinet expects defenders to find victims. Seven file-based indicators are published, with hashes.

• /data/lib/liblog.so — added. A malicious shared library.
• /data/etc/ld.so.preload — modified. This is the persistence hinge: it forces the loader to inject the attacker's library into every process that starts, including the mail daemons.
• /data/bin/webconsole and /data/bin/mailservice — added. Trojanised service binaries.
• /bin/smit — modified.
• /data/etc/httpd.conf — modified. Expect a new handler or alias that survives a restart.
• /data/migadmin.tar.gz — modified.

Two attacker addresses are named, 79.141.169.187 and 45.129.0.192; check firewall and NetFlow records for any contact with either. Beyond files and IPs, check the appliance's own configuration: operators have reported rogue mail-archiving accounts added through FortiMail's legitimate archive feature, quietly copying every message to an external host. Also grep the IBE logs for base64 decoding failures such as Invalid Base64 Encoding at pos 0, which look like exploitation attempts against the vulnerable handler.

Mitigations for IT security teams while you wait for firmware

1. Hunt before you change anything. Disabling IBE or rebooting can destroy the evidence you need. Collect file hashes and logs first.
2. Disable IBE. From the CLI: config system encryption ibe, set status disable, end. If your organisation relies on the portal, accept a service gap rather than an open gateway.
3. Take the management interface off the internet. Restrict administrative access to a jump host or management subnet. This is standard IT security hygiene that would have blunted half the edge-appliance zero-days of 2026.
4. Rotate everything the appliance held. Admin credentials, LDAP and Active Directory bind accounts, API keys, TLS certificates and any stored relay credentials.
5. Audit mail flow. Compare current routing, archive and relay policy against a known-good export, and confirm your MX records and outbound relays still point where you think they do.

Why a mail gateway is a DNS security problem

It is easy to file this under email and move on, but an email-gateway compromise is a DNS security incident as much as a mail one. Email is the protocol most dependent on DNS. MX, SPF, DKIM and DMARC lookups decide where a message goes and whether it is trusted, and a gateway with root on the box can be pointed at a resolver that answers those queries however the attacker prefers. An attacker who controls resolution on a mail gateway can quietly redirect outbound relay, defeat SPF alignment checks, or make a spoofed sender validate cleanly — without touching a single mailbox.

That makes resolver integrity part of the recovery checklist, not an afterthought. Confirm which resolvers the appliance and its network segment actually use, and whether query behaviour has changed. A run of our free DNS benchmark and network diagnostic tool from the same segment will show whether answers are coming from the resolvers you configured and whether network latency has shifted in a way that suggests interception. Where policy allows, moving resolution to authenticated encrypted transport closes the easiest version of this attack; our guide to DNS over HTTPS and DoT covers the operational trade-offs.

Industry impact: cloud security at the network edge

This is the fourth critical edge-security-appliance zero-day in six weeks. Readers who followed our coverage of the Citrix NetScaler zero-days will recognise the shape of it exactly: a device bought to provide cloud security or perimeter defence, internet-facing by necessity, running vendor firmware the customer cannot inspect, and carrying far more trust than any general-purpose server on the same network.

What distinguishes this one is the gap between disclosure and firmware. CISA's three-day deadline cannot be met by patching, because there is nothing to patch with. Federal agencies and everyone else have to meet it by configuration — which is the clearest possible argument that exposure management, not patch velocity, is the control that matters for server infrastructure at the edge.

The durable lesson for enterprise IT news readers is architectural. Security appliances deserve the same treatment as any other untrusted network service: management planes on an isolated segment, outbound egress filtered and logged, credentials scoped and rotated, and a tested answer to the question of how you would run mail for a week if the gateway had to be taken offline tomorrow. The next advisory will not come with a patch either.

Sources

• BleepingComputer — Fortinet warns of critical FortiMail flaw exploited in zero-day attacks
• The Hacker News — Critical FortiMail zero-day flaw exploited in attacks allows unauthenticated arbitrary file writes
• Fortinet PSIRT — FG-IR-26-175, FortiMail arbitrary file write
• watchTowr — Fortinet FortiMail CVE-2026-104286 FAQ
• HOL — FortiMail unauthenticated path traversal hits CISA KEV
• runZero — Finding impacted FortiMail appliances on your network

Independent editorial analysis published by DNS Benchmark Pro / Genext Information Systems. The Fortinet appliance photograph is by Premeditated, licensed CC BY-SA 4.0 via Wikimedia Commons; the Fortinet logo is the company's official mark, public domain, via Wikimedia Commons; the benchmark screenshots are original captures of the DNS Benchmark Pro engine. No images on this page are AI-generated. DNS Benchmark Pro is not affiliated with Fortinet.