The Cloud Customers Were Fixed in Four Days. What About the Rest of Us?

On October 1, Fortinet disclosed a critical flaw in FortiMail, its email security product, and confirmed that attackers were already exploiting it. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities catalog, according to multiple security outlets. Four days later, on October 5, Fortinet's own cloud version was patched. Customers running FortiMail Cloud did nothing and were protected.

Customers who run FortiMail on their own hardware or virtual machines got something different: a workaround and a to-do list. That gap is the story for your board.

What Happened

The flaw, tracked as CVE-2026-104286, scores 9.8 out of 10 on the standard severity scale. In plain terms, an attacker on the internet, with no password and no help from any employee, can send specially crafted requests to a FortiMail web interface and write files where they should not be able to. According to Fortinet's advisory, that is enough to run commands on the appliance.

Fortinet's advisory reports exploitation in the wild. That means this was a "zero-day": attackers used it before a fix existed. Fixed releases (8.0.2, 7.6.7 and 7.4.9) are now available. Customers on the older 7.2 line have no patch for that branch and are told to move to a newer one. Until then, Fortinet's workaround is to disable a feature called Identity-Based Encryption, or to keep the web interface off the open internet.

Why Your Board Should Care

An email security appliance sees everything: inbound mail, outbound mail, and often the credentials and policies that govern both. If you read my recent post on a similar Cisco flaw, the lesson is the same. The product bought to protect you can become the doorway.

But this incident adds a sharper question: who is responsible for the patch?

For the cloud customer, the answer was the vendor, and the vendor delivered within days. For the customer who runs the appliance in their own data center, the answer is you. That means someone has to know the device exists, know which version it runs, read the advisory, test the upgrade, schedule downtime, and apply it. Every one of those steps is a place where a critical fix can stall for weeks.

The Three Questions

In Cyber Risk Is Business Risk, I argue that boards need only three questions to cut through technical noise. Here is how they apply.

What can go wrong? The risk is not just this one flaw. It is that your organization owns internet-facing devices that nobody on the executive team can name. Attackers do not need to find your crown jewels first. They need one forgotten box.

What are we doing about it? Most companies can tell you their security budget. Fewer can tell you their security inventory. If the answer to "do we run FortiMail, and which version?" takes more than a day to produce, that is a finding in itself.

How do we know it is working? The measure that matters is time-to-patch for actively exploited flaws, tracked as a number the board sees, the same way it sees revenue or churn.

Compliance Is Not the Same as Security

Many organizations will satisfy their auditors by showing that a patching policy exists. A policy that says "critical patches within 30 days" looks fine on paper. It is not much comfort when attackers exploited the flaw before the patch was released and the exposure window is measured in days. The question for the board is not whether a policy exists. It is whether the organization can move faster than the attackers on the specific systems that face the internet.

There is also a liability angle. If a known, actively exploited flaw sits unpatched on a device and that leads to a breach, regulators and plaintiffs will ask when leadership knew and what it did. "We had a policy" is a weaker answer than "we tracked it and acted within the week."

What to Ask Your CISO This Week

1. Do we run FortiMail, and if so, is it cloud-hosted or on our own systems? Ask for the answer in writing, with the version number.
2. If it is ours, has the fixed version been installed, or has the workaround been applied? If not, who owns the date it will be?
3. Can anyone reach the management or webmail interface from the open internet? If yes, why?
4. Have we looked for signs of compromise? For a zero-day, patching today does not undo what may have happened before. Ask whether the team has reviewed the appliance for unexpected files or connections.
5. What is our average time to patch an actively exploited flaw on an internet-facing device? Ask for the last five examples.
6. Which of our security products could we move to a vendor-managed model, and what would we give up? Sometimes the cheapest risk reduction is handing the patching to someone whose job is to do it by Friday.

The Takeaway

Cloud is not automatically safer. But for one specific risk, who applies the fix and how fast, it moved the work to a team whose full-time job is fixing it. If your organization keeps the box, it also keeps the clock. Make sure someone on your team knows what time it is.