The Workaround Switches Off The Encryption. The Deadline Is Sunday.

On 1 October Fortinet published advisory FG-IR-26-175, disclosing CVE-2026-104286 in FortiMail: a path traversal combined with improper neutralisation of a NULL byte, carrying a CVSS base score of 9.8, which allows an unauthenticated attacker to write arbitrary files to the underlying system through a crafted HTTP or HTTPS request. Fortinet's own wording is that the flaw "has been reported to be exploited in the wild". CISA added it to the Known Exploited Vulnerabilities catalogue the same day, with a remediation date of 4 October for the United States federal civilian agencies it binds.

The advisory names the versions that fix it, and labels them in its own solution field as "upcoming": 7.4.9, 7.6.7 and 8.0.2. As at the time of writing those builds have not shipped, and Fortinet has published no release timeline. For anyone on the 7.2 branch there is no fix coming at all; the stated route is migration to 7.4 or higher.

So the remediation window opened on Thursday and closes on Sunday, and for the moment there is nothing to install. What Fortinet urges instead is a workaround, and the first one it lists is to switch off Identity Based Encryption.

That is the part worth a board's attention. This is not a story about patch cadence. It is a story about being asked to break one commitment in order to honour another, on a weekend, with no obvious owner for the decision.

What happened

• 1 October 2026Fortinet publishes PSIRT advisory FG-IR-26-175. CVE-2026-104286 is a path traversal (CWE-22) combined with improper neutralisation of a NULL byte (CWE-158) in FortiMail, at CVSS 9.8, permitting an unauthenticated attacker to write arbitrary files via crafted HTTP or HTTPS requests. The flaw was found internally by Fortinet's own product security team. Affected versions are 7.2.0 to 7.2.9, 7.4.0 to 7.4.8, 7.6.0 to 7.6.6 and 8.0.0 to 8.0.1. The advisory states the flaw has been reported to be exploited in the wild and urges customers to apply a workaround.
• 1 October 2026, same dayCISA adds CVE-2026-104286 to the Known Exploited Vulnerabilities catalogue, with a due date of 4 October 2026 under Binding Operational Directive 26-04. The entry carries the forensic triage requirement. Its required action instructs covered agencies to apply vendor mitigations in line with the directive and its forensics triage guidance, and then to "follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable". Known ransomware campaign use is recorded as unknown.
• 1 October 2026, same advisoryFortinet publishes indicators of compromise: four files added, being /data/etc/ld.so.preload, /data/lib/liblog.so, /data/bin/webconsole and /data/bin/mailservice, each with a published SHA256; three modified, being /bin/smit, /data/etc/httpd.conf and /data/migadmin.tar.gz; and two IP addresses, listed by Fortinet under the bare heading IPs with no infrastructure analysis. Two workarounds are offered. Disable Identity Based Encryption through the command line, or restrict access to the web based management interface to trusted networks.
• 2 October 2026Coverage across the security press confirms the fixed builds have not been released and that Fortinet has given no release timeline. No victim count, no scope assessment and no attribution has been published by anyone. No source we could find publishes a figure for the number of internet exposed FortiMail appliances.

Why this one is different

A great many advisories ask you to schedule a patch. This one asks you to choose which of your obligations to suspend, and it gives you until the weekend.

Identity Based Encryption is the mechanism FortiMail uses to deliver encrypted mail to external recipients who have no certificate of their own. The recipient gets a notification and collects the message through a secure portal. It exists precisely because most of the people a regulated business needs to send confidential material to cannot do S/MIME or PGP. In legal practices, insurers, healthcare providers and financial advisory firms, that portal is often the documented route by which client confidentiality commitments are met. Switching it off is not an internal change. It is a visible change to how clients receive sensitive correspondence, and in some firms it will touch language that appears in an engagement letter.

Fortinet's second workaround, restricting management interface access to trusted networks, is the better control and should be the default where it is achievable. It is also not free: managed estates, multi site deployments and outsourced administration models frequently depend on reaching that interface from somewhere the appliance does not currently trust.

Four options including waiting, and no shipped build among them. Each one takes something from a part of the business that did not ask for this.

One point of precision, because it matters and it is being blurred in coverage. Fortinet offers disabling IBE as a workaround. It does not state that IBE must be enabled for the vulnerability to be exploitable, and nobody should read the advisory as a guarantee that an appliance with IBE switched off was never reachable. Treat the workaround as risk reduction, not as a clean bill of health.

The indicator list is the part nobody is reading

Most organisations will skim the indicators, hand them to a security operations team and move on. They are worth reading closely, because the names describe a mechanism rather than a payload.

Among the added files is /data/etc/ld.so.preload. On a Linux based appliance, that file instructs the dynamic linker to load a named library into every process that starts. Alongside it is /data/lib/liblog.so, a shared library whose name follows the convention for a logging library. The modified files are named for the management binary, the web server configuration and the packaged administrative interface. We say named for rather than are, because no published source describes what /bin/smit or /data/migadmin.tar.gz actually do on this platform.

Our assessment, flagged as an assessment rather than a vendor finding, is that this is the shape of a mechanism designed to load into every process on the appliance and to influence what those processes record. Fortinet has published no analysis of attacker objectives and named no actor, so this is inference from names and nothing more. But if it is right, it carries a conclusion a board should hear: the appliance's own logs are not a reliable witness to its own compromise, and the evidence has to come from the network either side of it.

CISA appears to take a similar view of the forensic stakes. The KEV entry carries the forensic triage requirement, which directs covered agencies to the directive's evidence preservation guidance. The operational consequence is the same for everyone: an upgrade or a rebuild can overwrite the artefacts you would need to answer whether anyone was already inside. Collect first, then remediate. And absence of these indicators is not proof of a clean appliance.

Seven files and two addresses. The names describe a mechanism, and the mechanism sits in the path your evidence travels.

The commercial exposure for UK organisations

Regulatory. A mail gateway is not an ordinary appliance. Every inbound and outbound message passes through it, which makes it a concentration point for personal data and for commercially sensitive correspondence. If an organisation cannot rule out that an attacker had arbitrary file write and persistent access on that device, it is in the territory where UK GDPR Article 33 has to be assessed. Inability to exclude compromise is not by itself a notifiable breach; it is the trigger to investigate promptly. The clock starts once the controller has a reasonable degree of certainty that a breach has occurred, and from that point a notifiable breach must be reported to the ICO without undue delay and, where feasible, within 72 hours. So the threshold is awareness rather than confirmation of exfiltration, and the harder it is to interrogate the appliance's own logs the harder it is to reach either conclusion defensibly. Operators of essential and digital services face a parallel question under the UK NIS Regulations; EU entities in scope of NIS2 face their own incident notification duties, and financial entities face DORA's major ICT incident reporting. The UK Cyber Security and Resilience Bill remains before Parliament and is not yet law. Nothing here is legal advice, and whether any obligation is engaged turns on facts we cannot see from outside.

Financial. The direct cost is modest: an upgrade, when there is one to apply. The real cost sits in two tails. Forensic assurance on a device whose logging may itself be compromised is specialist work with an open ended scope. And if IBE comes off, the correspondence it carried either stops, moves to an unproven alternative, or goes out in a form that creates its own exposure. The second tail is usually larger, and it rarely appears in a security budget.

Contractual. This is the sharp edge. Where a firm has told clients, in an engagement letter, a data processing agreement or a security schedule, that confidential material is exchanged through a secure portal, switching that portal off is a change to a contracted process, not an IT configuration decision. It may be entirely justified and still require notice. The organisations that will handle this badly are the ones where a security engineer disables the feature correctly on Friday evening and the client facing teams discover it on Monday morning from a client.

Governance. The governance gap this advisory exposes is narrow and very common. Almost every organisation has a patch policy, an incident response plan and a change control process. Very few have written down who is authorised to disable a client facing security control as a compensating measure, what evidence that person needs, who they must inform, and who deputises when they are unreachable. That authority is not the same as incident declaration authority, and the two are routinely conflated until a weekend like this one.

What leaders should do now

1. Establish the running build, not the patch policy. Confirm the exact FortiMail version on every appliance, virtual machine and hosted instance, including any inherited through a managed service provider or a parent group. The affected ranges are 7.2.0 to 7.2.9, 7.4.0 to 7.4.8, 7.6.0 to 7.6.6 and 8.0.0 to 8.0.1. A report that the estate is patched is not an answer to this advisory. A build number is.
2. Collect the evidence before you change anything. Check for the seven indicator paths and the two addresses Fortinet published, matching on the full paths and the four published SHA256 hashes rather than on bare file names, and preserve appliance and network telemetry first. CISA attached a forensic triage requirement to this entry for a reason. Remediation that destroys the record leaves you unable to answer the only question a regulator or a client will actually ask.
3. Choose the mitigation deliberately, and tell the people it affects. Restricting management interface access costs less externally than disabling Identity Based Encryption, and should be preferred where it is achievable. Where IBE has to come off, the client facing teams need to know before it stops, with a holding line for clients, not after the first call comes in.
4. Treat the 7.2 estate as a project with a named owner and a date. There is no fix in that branch. Migration to 7.4 or higher is change control, testing and a maintenance window, and it will not happen because someone adds it to a backlog this afternoon.
5. Write down who may switch off a client facing control. One named person, a defined evidence threshold, a notification list and a deputy. Agree it this month, in daylight, rather than discovering at nine on a Friday evening that nobody holds the authority.

Three actions for today, and two governance decisions that outlast this advisory and the next one.

Three questions for the board

1. Who in this organisation is authorised to switch off a control we have promised to clients, in order to close an exposure we cannot currently patch, and who must they inform before they do it?
2. Which of our security controls, if compromised, would be unable to tell us that they had been, and where would our evidence come from instead?
3. When a vendor's only available remediation is a workaround, who decides whether we accept the residual risk, take the system out of service, or carry on, and on what written standard?

The strategic takeaway

The industry has spent a decade building the machinery of patch management: inventories, cadences, service levels, catalogues of exploited vulnerabilities and the deadlines attached to them. That machinery works, and it did its job here. The advisory published, the catalogue entry followed within hours, the deadline is public.

What it cannot do is make the decision when the remediation does not exist yet. In that gap every option is a trade between obligations, and trades between obligations are governance questions, not engineering ones. An organisation that has pre-agreed who makes that call will move this afternoon. One that has not will spend the weekend finding out, and will decide badly, late, and without telling the people it affects.

That is the capability worth funding. Not another scanner, and not a faster patch window. A written answer to the question of who is allowed to break something on purpose, and what they owe the rest of the business when they do.

Confidence note

Confirmed. From Fortinet PSIRT advisory FG-IR-26-175, published 1 October 2026: that CVE-2026-104286 is a path traversal (CWE-22) and improper neutralisation of a NULL byte or NULL character (CWE-158) in FortiMail; that it carries a CVSSv3 score of 9.8 with the published vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:P/RL:O/RC:C, the last three metrics being temporal: exploit maturity proof of concept, remediation level official fix, report confidence confirmed; that it allows an unauthenticated attacker to write arbitrary files via crafted HTTP or HTTPS requests; that affected versions are 7.2.0 to 7.2.9, 7.4.0 to 7.4.8, 7.6.0 to 7.6.6 and 8.0.0 to 8.0.1; that the named resolutions are 7.4.9, 7.6.7 and 8.0.2, each described in the advisory's solution field as "upcoming", with migration to 7.4 or higher the stated route for the 7.2 branch; that the workarounds offered are disabling Identity Based Encryption or restricting management interface access to trusted networks; and and that the indicator set comprises /data/etc/ld.so.preload, /data/lib/liblog.so, /data/bin/webconsole and /data/bin/mailservice added, each with a published SHA256, and /bin/smit, /data/etc/httpd.conf and /data/migadmin.tar.gz modified, with two IP addresses listed under the bare heading IPs. Found internally by Fortinet product security. From the CISA catalogue data, read directly: added 1 October 2026, due 4 October 2026 under BOD 26-04, forensic triage field set, known ransomware campaign use recorded as unknown, and a required action offering the cloud services route or discontinuing use of the product where mitigations are unavailable.

Assessed, and a point of care on exploitation language. Fortinet's advisory says the flaw "has been reported to be exploited in the wild", while the same advisory also sets a Known Exploited field to Yes and carries RC:C, report confidence confirmed, in its vector. We have not treated the quoted sentence as a hedge the vendor did not intend. The narrower and still accurate point is that Fortinet publishes no exploitation detail, no timeline, no victim count and no actor, so what is confirmed is that exploitation occurred, not its scale or character. We have found no published victim count, scope assessment, attribution or campaign linkage, and assert none. Our reading of the indicator set, that ld.so.preload with a library named for logging describes a mechanism loading into every process which may influence what those processes record, is a GCS assessment inferred from file names; Fortinet publishes no analysis of attacker objectives. Our account of what Identity Based Encryption is used for in regulated firms, and the commercial and governance arguments here, are judgements rather than findings.

Not known. When the fixed builds will ship; Fortinet has published no timeline. How many organisations are affected, in which sectors or countries, or who is responsible. Whether Identity Based Encryption must be enabled for the flaw to be exploitable; the advisory offers it as a workaround and does not state it as a precondition, and we do not treat a disabled feature as evidence of safety. How many FortiMail appliances are internet exposed; we could find no published figure and have deliberately not estimated one. What /bin/smit and /data/migadmin.tar.gz do on this platform, which is why we say named for rather than are. The 4 October date binds United States federal civilian agencies under BOD 26-04 and is not a UK or EU legal deadline. Nothing here is legal advice.

Garzon Cyber Solutions delivers cybersecurity advisory, compliance certification and specialist technology recruitment as one integrated capability for organisations in the UK, EU and Americas. We are a young firm and we publish our own research. Founder Jonathan Garzon spent his career selling cybersecurity, compliance and technology to security and technology buyers, working alongside marketing and technical colleagues, before building GCS around a single argument: delivered in the right order, security, compliance and the people to sustain them stop being three cost lines and become one commercial capability.