What should teams do first when FortiMail is exploited?

How to respond first after FortiMail exploitation is suspected

The first priority is to reduce exposure, not to wait for a perfect diagnosis. If the appliance is directly reachable from the internet, take it out of that path where possible, then confirm whether the installed version is among the affected releases. Treat the system as time-sensitive: if patching cannot happen immediately, use the vendor workaround and assume the workaround itself needs verification.

That order matters because exposed email appliances are attractive targets for rapid follow-on abuse, including credential theft, persistence, and pivoting into adjacent systems. The same playbook applies to any actively exploited edge product, so teams should work from containment first, then validation, then remediation.

How to verify exposure without delaying containment

Confirm exposure in two parallel tracks. First, check whether the appliance is reachable from outside the network and whether any upstream controls can narrow access immediately. Second, verify the exact version and compare it with the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog. That lets teams decide quickly whether they are dealing with a known exploited condition rather than a generic software issue.

Where possible, use the vendor advisory and the NIST National Vulnerability Database as the authoritative references for version and product specifics, then map those findings to your own asset inventory. For internet-facing mail security appliances, version mismatch alone is not enough, because exposed management paths, stale exceptions, and undocumented copies of the service can leave the environment vulnerable even after the obvious instance is isolated.

What to do if patching must wait

If emergency patching is blocked, apply the documented workaround immediately and treat it as a temporary control, not a stable fix. Then verify that the workaround is actually in place and has not been altered, bypassed, or partially applied. For actively exploited products, FIRST EPSS can support prioritisation, but confirmed exploitation and vendor mitigation guidance should override normal backlog ordering.

Do not let the exception become a parked risk. The operational question is whether the appliance can still be reached, abused, or laterally leveraged before maintenance opens. If the workaround requires configuration changes, review those changes for tampering, unexpected file drift, or any signs that an attacker has already modified the device to preserve access.

Risk and Threat Considerations

Exploited edge appliances compress the defender's response time because attackers get a trusted foothold near email, authentication flows, and internal administrative paths. The immediate risk is not only service disruption, but also post-exploitation persistence and reuse of the device as a staging point.

Failure mechanism: The appliance remains internet reachable, the vulnerable version stays in service, or the workaround is incomplete or modified, allowing continued exploitation or hidden persistence.

Impact: Attackers can preserve access, steal data, disrupt mail handling, or use the appliance to move toward higher-value internal systems.

Practitioner Guidance

What to prioritise: Containment comes before clean-up. Remove direct exposure first, then verify version status, then patch or mitigate. If those steps are done in the wrong order, teams often spend time investigating while the device is still reachable.

What to verify: Check the appliance itself, any load balancers, reverse proxies, firewall rules, and admin access paths. A mitigation is only real if the external attack surface has actually changed and the workaround has not been tampered with.

Practitioner takeaway: When a mail security appliance is actively exploited, the right first move is to shrink the attack surface and force a controlled maintenance path, because every hour spent debating patch timing is an hour the device may still be exploitable.

Related resources from NHI Mgmt Group

• What should security teams do first when a Windows privilege-escalation CVE is already being exploited?
• What should security teams do first when a widely exploited library flaw is disclosed in production software?
• What should security teams do first when a critical SharePoint RCE is being actively exploited in the wild?
• What should teams do first when a Check Point gateway vulnerability is being actively exploited?