Fortinet FortiMail administrators have a new emergency item to handle: a critical zero-day vulnerability is being exploited in the wild and has been added to CISA’s Known Exploited Vulnerabilities catalog. The flaw, tracked as CVE-2026-104286, carries a CVSS score of 9.8 and can allow an unauthenticated attacker to write arbitrary files to the underlying system through crafted HTTP or HTTPS requests.

Treat this as an emergency exposure-reduction task, not a routine patch cycle. Email security gateways sit at a sensitive boundary, often exposed to the internet and deeply integrated into mail flow, identity, encryption, and administrative workflows. A file-write primitive on that class of appliance can quickly become a foothold for persistence, credential theft, mail interception, or broader network access if the management plane is reachable.

What is affected

According to the Fortinet advisory cited by The Hacker News, the vulnerability is tied to path traversal and null-byte handling weaknesses. The affected FortiMail versions include:

- FortiMail 8.0.0 through 8.0.1
- FortiMail 7.6.0 through 7.6.6
- FortiMail 7.4.0 through 7.4.8
- FortiMail 7.2.0 through 7.2.9

Fortinet’s recommended upgrade targets vary by branch. Some fixes are listed as upcoming maintenance releases, while FortiMail 7.2 deployments are directed to move to the 7.4 branch or later. That detail matters operationally: teams should not assume that staying on an older long-running branch is enough if the fixed build is not available there.

Why this vulnerability is high risk

The most important detail is not just the CVSS score. It is the combination of three conditions: unauthenticated access, network-reachable HTTP or HTTPS handling, and confirmed exploitation. When attackers do not need valid credentials, the defensive margin becomes much smaller. If a vulnerable FortiMail interface is reachable from the internet, the window between discovery and compromise can be short.

Arbitrary file writes are especially dangerous on appliances because defenders may have limited endpoint telemetry, limited shell access, and fewer standard response tools than on general-purpose servers. Attackers know this. Security appliances are attractive targets because they are trusted, frequently exposed, and sometimes monitored less like servers and more like “black box” infrastructure.

Immediate containment steps

Fortinet has advised customers to apply workarounds where fixed versions are not yet available. The two practical priorities are:

  1. Disable FortiMail IBE feature support using the vendor-provided CLI guidance if your environment can operate without it.
  2. Remove internet access to the FortiMail management interface, or restrict it to trusted private networks only.
The second action should be treated as a baseline control, not just a temporary mitigation. Management interfaces for mail security appliances should not be broadly exposed to the public internet. If remote administration is required, place it behind a VPN, zero-trust access proxy, jump host, or tightly scoped allowlist with monitoring.

For many organizations, the fastest safe move will be a firewall or security-group change that blocks public access to FortiMail administration while preserving required mail-handling traffic. Make sure the change is tested carefully so that SMTP flow, inbound filtering, outbound relay, quarantine access, and user-facing functions are not unintentionally disrupted.

Hunt for signs of compromise

Fortinet has published indicators of compromise that include suspicious IP addresses and file paths reportedly associated with exploitation. The file indicators include added or modified components such as shared libraries, web console or mail service binaries, preload configuration, and HTTP configuration changes.

Do not rely only on matching IoCs. Treat them as starting points. Review FortiMail administrative logs, web access logs, configuration change history, unexpected service restarts, anomalous outbound connections, and new or modified files around the likely exposure window. If centralized logging is available, search for unusual HTTP or HTTPS requests to FortiMail management endpoints, especially from unfamiliar external IP addresses.

If you find matching files or unexplained changes, preserve evidence before rebuilding. Capture logs, configuration snapshots, firmware version information, network flow data, and any available file metadata. Then follow an incident response path rather than simply deleting suspicious files. A compromised mail gateway may expose message content, routing rules, administrator credentials, certificates, API keys, or integration secrets.

Patch planning and validation

Where a fixed release is available, prioritize upgrade testing and deployment. Where the vendor fix is still upcoming for a branch, apply the workaround and verify that the vulnerable exposure is actually removed. A mitigation is only useful if it is confirmed from the attacker’s point of view.

Recommended validation steps include:

- Confirm the FortiMail version and branch on every appliance, including standby or disaster-recovery systems.
- Check whether the management interface is reachable from the public internet.
- Verify IBE status if using the recommended workaround.
- Review firewall rules, NAT rules, reverse proxies, and cloud security groups for accidental exposure.
- Monitor for new vendor advisories and install the fixed build as soon as it is available for your branch.
- Document business impact if IBE or remote administration is disabled temporarily.

CISA has given U.S. federal civilian agencies a short remediation deadline, which is a useful signal for everyone else: this is not a “patch when convenient” advisory. Even if your organization is not bound by CISA deadlines, active exploitation should drive emergency change-management handling.

Bottom line

FortiMail systems should be inventoried immediately, internet-exposed management access should be restricted, and available vendor mitigations or upgrades should be applied without delay. After containment, teams should perform compromise assessment rather than assuming that the absence of visible symptoms means the appliance is clean.

Source: The Hacker News report