FortiMail: The Box Inspecting Your Mail May Be Reading It
An actively exploited, unauthenticated file-write zero-day puts the appliance that terminates your inbound mail into assume-breach territory — and the blast radius is the signing keys it holds, not the firmware.
Why a mail gateway is the worst appliance to lose
The flaw is an unauthenticated arbitrary file write. On an appliance, that primitive escalates to code execution and persistent implants by overwriting web-served paths, scheduled jobs, or configuration. It tops the week for one reason. Secure email gateways almost never run EDR, so an implant sits in a telemetry blind spot that endpoint tooling never queries. The defensible starting posture is assume-breach for any instance exposed before patching. The published advisory excerpt omits the CVE ID, CVSS, affected builds, and KEV due date. All four are in Fortinet PSIRT and the CISA KEV entry. The response proceeds without waiting on the missing identifier.
The stolen secrets outlast the patch
FortiMail terminates inbound SMTP and decides what gets quarantined and what gets delivered. It also holds three categories of secret that survive any firmware fix:
- DKIM signing keys. Stolen, they let an attacker sign outbound phishing that passes DMARC as the victim's domain.
- TLS private keys. Mail can be read in transit.
- LDAP/AD bind credentials used for recipient verification. They give a foothold into the directory.
A patched appliance can still be compromised. Confirming it wasn't is a separate, mandatory step.
Patch, then prove it
The firmware update and the compromise assessment are two distinct jobs. The assessment starts with a diff of the running config against the last pre-disclosure backup. Attacker changes that route mail outward show up in admin accounts, delivery/BCC/forwarding policies, safe-sender lists, and quarantine-release logs. The appliance's outbound connections get baselined. Any indicator hit means a rebuild from a clean image. Patch-in-place is off the table at that point. If the assessment shows mail access or exfiltration, the GDPR Article 33 72-hour clock and the SEC materiality assessment are live. Legal joins before the answer is known.
The vendor-concentration question
This is a recurring Fortinet event. The vendor's perimeter products have landed in KEV repeatedly. An organization running Fortinet for its firewall and VPN as well as its email gateway has placed most of its internet-facing exposure under one vendor's secure-development lifecycle. That belongs in the next review as a vendor-concentration finding. Mid-incident rip-and-replace is the wrong response to it. The nearer second-order risk sits with partners. A compromised supplier or MSSP FortiMail delivers the most convincing business-email-compromise users will ever see, because it arrives through a mail path they already trust.
What to do
Inventory every FortiMail instance — hardware, VM, Fortinet-hosted, and MSSP-managed — and apply Fortinet's fixed build or interim mitigation today; where you cannot patch immediately, restrict all admin and web interfaces to a management network.
Run an assume-breach compromise assessment on any instance exposed before patching, then rotate every gateway-held secret within 72 hours — admin credentials, LDAP bind (re-scoped read-only), a new DKIM selector with the old one revoked, and TLS certificates.
Ask tier-1 vendors and MSSPs in writing by end of week whether FortiMail sits in their mail path and whether they have assessed for compromise.